Friday, 22 February 2008

Brute forcing a solution


It should be fun. That means it should be interesting. That means there should be choices, and those choices should be meaningful. It has to last long enough that choices can be made on the timescale of a turn based game. It has to be short enough that it doesn't degrade into a boring repetitive action. Ideally, a tough fight should see both participants gain and lose the upper hand a few times before one eventually emerges victorious.

Not a particularly easy problem.

As a small step forward, I wrote a little simulator that brute-force optimises combat stances for a particular flavour of opponent. The results are, well, I wouldn't say interesting, but they give a concrete starting point.

The results are split into two categories:
  • The first tries to optimise for efficiency i.e. maximising damage dealt for a given energy (time) budget. This kind of stance represents the optimum for battles of attrition - versus a horde of small things or one immensely tough creature.
  • The second tries to optimise for speed in terms of actions (turns) i.e. the minimising number of attacks to dispose of a foe. This should be ideal for dispensing a slow stream of foes one-on-one, where killing something in a few hits and moving on is preferable. This is how most action in Roguelikes seems to take place, during dungeon exploration.

The attacker has a fixed attack skill value, whilst the defender varies in both defense skill and damage soak. In these contour graphs, soak is on the x-axis and defense skill on the y-axis (bottom left is 0 skill, 0 soak).

The bland blue colour is 0, whereas the brighter turquoise is 1. Red-yellow-purple are approximately evenly spread between these extremes. The big flat blue areas in the top-right of the charts represent areas where the soak/defense prevented damage entirely.

Yep, they're horrible and noisy, and I really hate Excel. So much. Especially this hideous '2007' offering. That aside, it's helpful to see the problems with my current implementation.

The most obvious issue is that speed is useless in these scenarios. There's a fringe case for efficient slaughter of creatures with negligible defense and armour, but really that's a tiny local maximum. Damage also appears under-represented, especially in its intended niche of fast dispatch, although this is not as badly nerfed as speed. Accuracy therefore dominates, especially as soak and defense increase. The latter is desirable, but after poking around I suspect the former is not.

So my current thoughts are to increase the effect of speed across the board, remove the armour-piercing quality of accuracy, and slightly increase the effect of damage on the overall calculation. Implementing a less crude optimiser and some way to visualise the data without using Orifice would also be nice...

No comments: