Spent an hour or so at work rendering some trees. I think I might re-render with the saturation turned down on the leaves just a tad; they seem awfully bright, especially since I turned down the sat on the ground splats. I also only had 1 leaf texture, so I'll probably create a couple more leaves and redo some of the trees to give a bit more color and leaf variation. Still, I'm pretty glad I resurrected that old script.

I spent quite a bit of time during slow spots at work today working on the rogue-like combat state. I've said it before, but doing turn-based is sometimes tough, especially turn-based of the rogue-like variety. It's trivial if you don't have to worry about animation; if your entities can just "jump" from square to square. omnomnom was wrestling with a similar situation awhile back, and he found a solution that seems to work for him. I've never really found a way that works for me, and today was no exception.

Here's the situation. In a roguelike, the player can move square by square or can perform any number of actions: casting a spell, zapping a wand, etc... Each action consumes some amount of time, or number of turns. After the action is performed, any surrounding enemies take their turns. Some of the enemies may be faster than the player, and in the time it takes the player to do one attack, they might be able to do 2. As long as the simulation doesn't need to account for animation, this is trivial; you just loop while the enemy still has turns to do, and do the actions. The only feedback goes into the scrolling combat log, or maybe some cheesy and hacked ASCII animation. When you have to take into account animation, though, things get a little more hairy.

Say the player takes a step. As long as everything moves the same speed, and everything else is just taking a step, then the simulation is easy; have everything take a step at the same time. The animations are the same length, when one is done animating and stepping they are all done animating and stepping. But what about that one guy that's slower than everything else? He quaff-IDed a potion of slowness and is carrying 150 lbs of cursed chain mail plus a weightstone; honey in winter moves faster than this poor knucklehead, so while everyone else takes one full step, he can only take a partial step. Problem. Partial steps aren't allowed in a roguelike. So now what do we do? You can kind of solve the problem by multiplying his turn-time by a fraction depending on his slowness, and accumulating turn-time until he has enough time to take one step. However, the real problem comes if this slow-ass, weighed down bonehead is the player himself, since the player sets the baseline movement rate for everything else.

If the player takes a step at such an extreme amount of slowness, to the player's perceptions the character is moving normally; however, to every other entity, it now means they have accumulated a large amount of turn time and can do multiple turns. The hard part is cramming all of those animations into the time it takes the player character to take a single step; the result is either a long, long wait while the player is delayed so that all actions can be executed at a normal visual pace, or extremely frenetic activity as all of that is compressed into a single turn.

This isn't even the worst scenario. It gets really complicated when you have guys casting multi-turn spells, guys moving with haste, players that want you to implement auto-run so that you will move until something disturbs you, etc... Down in the trenches of scheduling turns and animations, it gets pretty confusing pretty fast.

I made a good start with it, although I haven't implemented haste/slow. But I'm thinking that I will set that aside. I've got a pretty solid system going with the party-based turn system. It works pretty well, as long as you segregate travel mode and combat mode. My thinking with trying to do the roguelike combat system was that I wanted to eliminate travel mode, and just have the whole game play out in combat mode, something that would be tricky and probably tedious with the current combat kernel, given that every entity acts separately in their turn. With a whole level full of enemies, this would slow gameplay to an absolute crawl. Hence combat mode, where an encounter is generated as a small sub-map, and a fade-in transition from Travel mode is effected. Once the encounter is beat, the player can either spend some time prowling around the combat map, seeing what secrets might lie within, or they can just exit back out to Travel mode.

I'm not 100% in love with having 2 modes; I've never really been a huge fan of it. It is entirely possible that I might still hack on the roguelike state, or tweak my current setup, in order to eliminate Travel mode. But for the nonce, I'm not going to split my attention on this any more.

One big plus of Travel mode is that it considerably boosts the effective "size" of the world, or at least of each individual island. I currently generate each island as a 200x200 hex map, which is pretty big even if a lot of that is water; still, if each hex represents a smaller scale sub-map that the player can explore, that increases the amount of territory available on each given island tremendously; if a sub-map is, say, 64x64 hexes, then that makes the entire island effectively 12800x12800 hexes, a pretty decent chunk of ground even taking away the mountains and water.

Never fear, though; even though I probably won't present a choice of 2 combat modes for testing, I still plan to upload a small demo for feedback purposes, to get a feel for how people like the turn-based combat gameplay.