Oxtongue Heroes

This is the first game I've really used source control on, and it's interesting the way it shows me exactly how long it's been since I really added anything useful to the project. There's a long period of a little better than one update a week, ending May 20. One inconsequential update on August 28. And now, one major update on November 19.

Yesterday's (well, yesterday's when I started writing this) update was a rework of how the view-and-control package accomplishes control flow and concurrency. The benefits are mostly for maintainability, modifiability, and later reuse; nothing that players should be impressed to hear, in other words, but it'll help me out. Coming out of a long period where the game was unbuildable, I'm reminded of something I once posted - it makes so much difference to motivation to be able to play something, see something to change, change it, then see it changed; it seems like I've made a million little interface improvements since the last commit. (Half of that was fixing bugs introduced by the refactoring, of course. But it still feels good!)

Anyway, RL circumstances have eased off a bit, so with that done I'm looking forward to something more like the one-per-week update schedule; but I've typed this much and not even talked about movement or position yet!



The first time I tried to write this, it kind of turned into just a list of lots of things Oxtongue Heroes does relating to movement. The trouble is that movement is central to a tactics RPG. It's the defining feature of the genre and the central determiner of who can attack who with what, when; it has enormous impact on tactics and pacing. Rather than make up a list that touches on so many features that comprehensively, my inclination is to just work on the game and let people eventually see. (That is, after all, one of the neat things about games - they are good at getting people to learn the consequences of rules.)

So instead, I'll focus on a movement and position issue that I've kept in mind while designing, and reserve further comment for future posts.



Square-tile 4-direction movement causes some funny things. Paramount among them:


In both these cases, attacker 'A' is six spaces from defender 'D'; if he can only attack adjacent, he needs to move five tiles to do so.

But in the top case, A has exactly one shortest path to D. Place an obstacle anywhere in that five-tile line, and A will have to detour around it, adding two spaces to his movement cost. While in the bottom case, A has lots of paths to D. 20, to be exact, but what's more important is that no single obstacle will even slow him down. It takes two obstacles right next to A or right next to D to cause a two-tile detour. And if A has an attack range one or two tiles longer than just adjacency, on the bottom it becomes much more difficult to block him without a few units close to where he starts off - whereas on the top, of course it's harder to stop him, but there are still three of five spaces where a single obstacle will do it.

Tile-based movement is nice for lots of other reasons, but this is a pain. I had very little interest in having positioning dictated entirely by this straight-line principle, but I did want to have potentially wide-ranging movement and still give single defenders the ability to, well, defend. (I don't remember how much I've said about the battle-scoring system, but the way I hope players will find a difficulty that is comfortable for them is, on the whole, to bring fewer units to battles. That works a lot better if the effectiveness curve looks more like "one unit can delay them a turn, two units can hold them off for several turns, three units can beat them in a few turns" than "three units can beat them, less might as well not be there at all".)

This is certainly part of the reason OH has both diagonal movement (at 1.5x cost) and ZOC.