Oxtongue Heroes

A short note as I acknowledge that Oxtongue Heroes has been on hiatus for effectively a year:

From the start of real work on it, I considered the main purpose of OH to be to perform an experiment. That was around the time I found out about the field of constraint programming. It had immediately caught my interest, in part because of the math connection and in part because using it would make an entire decent-sized solver I'd once programmed for another minigame (not on RMN right now) basically unnecessary.

So, I wondered how well I could get it to work with a harder-to-define problem: what the enemy should do on a given TRPG turn. The ideal case would be to have map-designer-determined objectives, typically things like "KO as many player units as mathematically possible, and do as much total damage as possible to the rest". But I knew that was a large problem space and I'd probably have to cut down on it somehow; the experiment was to find out whether I could find tradeoffs leading to a reasonable result.

In short, I didn't. I guess for brevity's sake I won't get into depth here. Despite occasional encouraging signs, I never got things on the AI to a point I was really happy with.

If I choose to entirely or almost entirely switch to a more conventional AI strategy, it leaves the rest of the game in a curious state. I'd kept the investment in plot really low largely because the gameplay experiment was risky. That just leaves (orphaned?) gameplay elements to look at - for example, having wholly deterministic damage was forced by the choice of AI! (Insofar as I'd been making a game with symmetric mechanics, at least.)

(Though I'll spare a paragraph to say: undo and the action queue, which occurred to me mostly because I did have determinism to work with, are a really handy UI element I'd want now in any game where I have to coordinate large numbers of sequential actions on a turn. I probably undersold that feature in the alpha release.)

So, though there remain ideas here I'd like to come back to sometime, I wouldn't be continuing this game without some re-evaluation. Thanks to my testers and subscribers for your support, and if anyone has any suggestions or comments, I'm here.

My God, it's full of gray!





The central menu is about 95% done. (Box and font prettiness is not part of that total - I certainly plan on it, but not for the v0.7 release.) It tends to feel more like a burden to work on something when trying out battles isn't part of the testing, so I'm relieved to be back to a point where I can start battles and load saves.


So, about score!

I've posted before (here at least) that the mechanisms many RPGs have for regulating battle difficulty often don't work too well. I tend to attribute this to a few reasons: they're tied up with other things the player may want to do (sure, the fight will be harder if I don't explore), they look like in-game decisions (gee, not sure how far it is to the next save point, my smart option is to grind a bit), or in fact the reward for smart play actually makes the game easier (loot).

One of the things I aim for with Oxtongue Heroes is to accommodate a wide range of player skill with pretty fine granularity - basically, to get self-regulation of difficulty by the player. I hope this can be accomplished by getting the player to deploy no more force than he needs to beat each map, or close to it. Being able to deploy less units than might be useful is very far from a new thing, but in most tactics games I would hardly even consider it on most playthroughs; OH does a couple things to encourage the player to play along.

The first, paradoxically, is that there's no unit cap - if you want, you can send out all 17 PCs on every map. That should be overkill enough on most maps that people get the idea that completing every battle is not the sole thing they can be aiming for.

And the second is the score. The scoring penalizes you both for using lots of force, and for reusing the same characters across several battles while ignoring others; so the player has to both minimize numbers and figure out how everyone would be most useful. (The number in the screenshot is provisional, I haven't entirely settled on the formula yet.)

Nothing's going to force players to play to the score, and if someone doesn't want to I don't really have a problem with that; but I think it will improve a lot of experiences.


-------

Stuff to do before projected demo release

- Finish enemy deploys in the third map and test for balance
- Create and finish the fourth planned map
-- write AI modules that take advantage of NPC mages (actually didn't go with straight-up mages for this map, did it a bit different)
- Create a tutorial map
-- Let status effects be loaded from the map file that can show message boxes
- Show battle objectives from the end-turn menu
- Tie the battle maps together with a hub and scoring
- Other problems as they come up (ongoing)

The hub has occupied basically all my OH attention for the last month - nothing's done on the tutorial. So things will probably still be a while.

Before I started working on this game, I'd had about half a dozen projects that started with a clear gameplay idea. In every case, within about two months of starting I had a demo out, something people could play and understand what the game was. If I continued with it, of course details got tweaked, but the basics were all there.

Though I'm busier now, I'm still sometimes boggled by the length of time it's been taking to get this together to the point where I feel all the interlocking bits are there enough to really start getting feedback on it as an actual game.


About two years ago, when I started actual coding on this, I had a clear idea of a lot of the features that I thought would make a workable, interesting turn-by-turn tactics RPG:

- AI that determined what to do based on what several units could accomplish together, not just what would be good for each unit;
- A varied group of ~15-25 characters, from which the player got to pick basically any group for each battle, aiming for ~3-10 per battle for a good player;
- A system for tying together the groups used in battles to produce a score, so as to encourage the player not to focus on a single unit or combination of units, and in general to use as few units as possible;
- To go with the above point, no leveling;
- Deterministic damage and combat results, which has a bunch of benefits (undoability, possibly cheating protection for the above scores, the AI can do more);
- A pretty good sense of how I wanted movement, territory control, and ability ranges to work, and the basic mechanisms I'd accomplish that with;

This is still what I'm aiming for. Certainly details have been filled in: I dumped my first try at a deterministic damage mechanic for another, I had to work up what sorts of unit abilities might be interesting and get them to work right with the AI, lots of other stuff (a lot of that over the last year, even though I thought a year ago most of what was left was frontend work); but it's not like I've been overhauling the entire game concept every few months.

Heading in I tried to think of this as an experimental game, because I knew working up a game with the sort of AI I had in mind would be tricky. I didn't appreciate how much of the game it would make tricky, because at some level a lot of my problems come back to getting that right. But once this stuff is done it's much easier to reuse, and I'm still plugging away.



Stuff to do before projected demo release

- Finish enemy deploys in the third map and test for balance
- Create and finish the fourth planned map
-- write AI modules that take advantage of NPC mages
- Create a tutorial map
-- Let status effects be loaded from the map file that can show message boxes
- Show battle objectives from the end-turn menu
- Tie the battle maps together with a hub and scoring
- Other problems as they come up (most dangerous point, heh)

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.

Yesterday I totally reworked the damage system, completely replacing every stat that had anything to do with attacking.





This might sound like a difficult change, or conversely like I have very little done on anything in the game, but really neither is true. I'd known the exact damage equation was not too essential until I started producing significant quantities of units - basically, drawing up and testing actual battle maps. At that point it would have to meet certain goals that I did have already in mind (though perhaps not all this formally):

-Comparative advantage: For most targets there should be a definite benefit of using certain attackers over others; for many enemy attackers there should be a definite benefit of forcing them to attack certain player units over others.

-Effectiveness slope: An imprecise term, but what I want to avoid is having a situation where, say, two PCs could do lots of damage and everybody else would be totally useless. It should be possible to replace a highly-specialized character with ~1.5-2 less-specialized ones, a less-specialized one with a couple anti-specialized ones; and these grades should all exist for most situations. And no PC should be next to useless versus all but a few enemies.

-Effectiveness range: I want to be able to design enemies who are considerably stronger than single player units, as well as enemies who are considerably weaker (but still potentially dangerous in aggregate). And heck, maybe PCs of different strengths too.

-Perturbability: Ideally, many buffs and debuffs will function by transparently changing stats. Such small changes should almost always have some effect and usually not result in totally huge effects on their own.

-Simplicity: Damage needs to be an integer, simple to calculate or at least estimate, and the comparative advantage should be easy to make obvious. Generally, the fewer numbers there are and the smaller they are, the better. Also, ideally, a bunch of enemy units on a map sharing a couple patterns of basic stats will be neither stupidly easy nor stupidly difficult just from sharing those stats.

-Complexity: I did want something a little more involved than "I am ROCK! I crush SCISSORS in one hit, crack ROCK in two hits, and cower before PAPER!" At least for this game.

-Perfect information: Everything's visible.

-Determinism: This is definitely not an ordinary genre requirement, but other aspects of the game design (perhaps to be touched on later?) called for never doing any random rolls. I also did hope this would help simplicity, as people can be surprisingly bad at working with probability. One needs little more evidence than the actual odds of hitting something in Fire Emblem.


I'm quite happy with how the new setup meets these criteria in preliminary testing. Hopefully there aren't too many steps left before I can start seriously making battle maps.



Below are details on the actual equations.
------------------------------------------------------

The Old Setup:
If your Accuracy > defender's Evade, that's a "hit": do your Strength - defender's Toughness damage (minimum 1 damage).
Otherwise it's a "miss": do 1 damage.
Stats were intended to be generally single-digit; the spread wasn't exactly fixed, but something like 0-6 for Evd and Tgh, 1-7 for Acc, 3-9 for Str.

Comparative advantage was good, simplicity was pretty good, and of course this was deterministic. This actually worked pretty well for the test battle I've been running through much of development, with two types of enemies both around PC strength.
But effectiveness slope was a problem: given any vaguely normal distribution of stats, high-Evade units could tank against just about anybody. This is particularly vexing when trying to create a boss unit - either high-Evade characters can easily tank it, or it can hit everybody so there's no point to throwing a high-Evade unit against it.
Of course it would be possible to cap the ends of the distribution - but it'd be nice for accuracy and evade effects to usually have meaning, without making someone totally unreachable.

Magic was also tricky. Magic abilities can't be used that easily, so I didn't want them to just be evadeable; I was hesitant to use toughness or a simple magic defense stat, since magic damage can come at several different potency levels; but making a static damage value for magic heavily favored low-Evade units.

I did work on several variations of this, enough that I won't list them, and some had greater potential merit, at the cost of some simplicity. But I never quite came up with a version I was satisfied with.

The New Setup:
Every unit has a Dodge classification: Fast, Medium, or Slow.
Every direct-damage effect has separate F/M/S attack values. These are monotonic - attack vs. Medium is always at least as high as attack vs. Fast.
A direct-damage effect vs. a Fast unit does its Fast attack value in damage, and so on.
Player-unit attack averages are around F4/M6/S8.

Some abilities or status effects can move a target's evade up or down a class (even to, for example, "Fast+1", which gets damaged one less than the Fast attack value) or give effects like "Ignore 1 damage", but these aren't all that common.