-
Morten Monrad PedersenDenmark
Automa Factory
Automa Factory
-
As mentioned in my previous post the kind of highly simplified bots I recommend making for board games carry risks of degenerate and exploitable behavior. Yesterday I talked about the former and today I’ll talk about the latter.
Exploitable behavior: Power curves
The first topic I’ll discuss in relation to this is something I call power curves (I haven’t seen any standard terminology for it). By that I mean scaling of the power of a player in a game, scaling of her victory point (VP) scoring, scaling in her progress towards winning the game, etc.
In many games the player gets more and more powerful as the game progresses. This goes for all engine building games such as Scythe, to take a game with which I’m intimately familiar. In Scythe there’s a system that triggers the end of the game (one player achieves 6 triumphs) and a semi-coupled system for scoring VP (in the form of coins) which is what determines the winner.
The coin scoring in Scythe ramps up during the game, because the player gradually builds up her engine.
When we designed the Scythe Automa (“Automa” is our name for the kind of bots we make) some years ago our first approach to handle the Automa’s coin scoring was for reasons of simplicity made so that the bot gains coins at a constant pace equal to the average of what a human player gains over the full span of an average game.
That meant Automa players and average human players would score about the same during a full game, they’d just do it with different speeds during that game.
That’s good, right? Well, not necessarily. To see why let’s consider the power curves for the two types of players.
1) Automa players scores VP at a constant pace, which means that its power curve is flat.
2) The human player scores VP at an accelerating pace.
The player’s power curve starts below the Automa’s and at some point crosses over so that the human’s power curve goes above the Automas and on average the areas below the two power curves (i.e. the number of coins earned) will be the same – which means that they score the number of coins.:strip_icc()/pic4052132.png)
Simplified version of the power curves in an early revision of the Scythe Automa.
That’s still well and good, but now imagine that the player can drag out the part of the game where his power curve is above the Automa’s. In Scythe this can be done by avoiding combat. If that happens the human player will be gaining more coins than the Automa for a longer time, thus exploiting the average-scoring simplification of the Automa’s VP generation in a gamey way to consistently win the game.:strip_icc()/pic4052131.png)
Simplified version of the power curves in an early revision of the Scythe Automa, where the human player exploits the Automa’s constant scoring pace to win by dragging out the game.
Overcoming power curve exploits
We realized that we had the power curve problem early in the design process and saw three overall approaches to fix it:
1) Modify the Automa’s power curve to be more like that of a human.
2) Modify the human player’s power curve to be flat.
3) Make sure that the game ends before the human player can exploit dragging out the game too much.
Approach 2) was discarded immediately, since that would heavily change the feel of the game, which we don’t want to do.
Since the approaches aren’t mutually exclusive, we decided to use both 1) and 3).
To implement approach 1) we divided the game into two phases and had the Automa gain more coins in the second phase than in the first, so that its power curve became closer to that of a human player.
To implement approach 3) we:
a) made the Automa more aggressive, thus making it harder to drag out the game by avoiding combat.
b) significantly increased the Automa’s pace of achieving triumphs (remember that 6 triumphs end the game) towards the end, so that the game would end at a reasonable time even if the player tried to extend the game.
Exploitable behavior: Simplistic movement rules part 1 - kiting
I talked about kiting as a degenerate behavior in my previous post in relation to World of Warcraft and will revisit that here from the perspective of exploitable behavior.
Let’s briefly refresh our memory and note that kiting is a technique where you move towards a monster in a group just far enough to come within the distance where the monster triggers and runs towards you, but outside the same distance for the other monsters in the group.
After that you run backwards while “kiting” the monster along with you. You can then either kill it off at a distance while running (if you can do ranged combat), attack it once you’re far enough away from the group that you don’t risk having to deal with the rest of them, or simply pull it away from something. On a more nefarious note you can pull powerful monsters into an area where there are many low level players or into the hometown of the opposing faction so that the monster kills off the NPCs there.
A severe case of kiting in World of Warcraft: A huge dragon is kited to the capital of the opposing faction.
In WoW I consider this a by-design degenerate behavior that to a large extent was made for performance reasons (this is a guess that’s not based on any inside knowledge). During the playtest of the Automa for Scythe we had a problem with a playtester using the third of those kiting types in a way that exploited the behavior in a way that we definitely didn’t intend.
The player was using the fact that Automa combat units move towards the player’s combat units while mainly ignoring workers. The playtester hurried his combat units to the opposite side of the board than his workers where so that the Automa’s combat units moved towards the side of the board where the playtesters combat units were i.e. opposite his workers.
He then spammed workers and then used them to spam resources like there was no tomorrow. He had no use of all those resources except that they’re worth VP at the end of the game and he could spam them so fast the he had a good shot at winning the game because of the stupid simplicity of the Automa’s movement system.
In a game against human players pulling of this strategy would be very hard. First, because a human player likely wouldn’t allow herself to be kited and second because all those resources lying there with zero protection present a sweet prize for the opponents to sweep in and take.
It wasn’t a surefire technique and I’ve only heard about 1 or 2 players pulling it off, but it’s still a gamey exploit and so we had to deal with it.
To fix this, we put a maximum on how many resource per space a player can use to gain VP at the end for the game. It’s most definitely not a fix that I’m proud of, quite the contrary – it’s the biggest design kludge I’ve ever made, but it got the job done.
Exploitable behavior: Simplistic movement rules part 2 – circle strafing
It’s not only the Scythe Automa that has trouble moving units intelligently around on a board with many spaces. Another example is The South Shall Rise Again.
TSSRA is a game set during the American Civil War and is based on the little-known fact that the Confederates (the Southern states) used zombies to fight for them. OK, OK, it’s not a fact, but it would be cool
.
The game has a traditional wargame hex board with a lot of zombies moving around trying the kill the player-controlled Union (the Northern states) soldiers. The game has the distinct advantage that the units it has to control are braindead and so the designer could create realistic behavior by simply having the zombies move directly towards the soldiers.
While that’s nice for the designer in relation to do a realistic simulation of enemy movement, it still caused a problem gameplaywise (assuming I’m playing the rules correctly, which of course I might not).
After playing the game a bit in the way I think it’s intended, I came up with a strategy where I ran in circles around the edges of the board (well, technically it was rectangle). I would then stop, shoot, and when the zombies got close to me, I continued my circle around the board and the zombies would follow me crossing back over the center of the board.
While it was not a sure win this “circle strafing” (to borrow another term from video games) strategy gave me the best winning chance that I could find and I’m pretty sure it was not what the designer had in mind. It also made the game take a very long time, since there was a lot more running than fighting.:strip_icc()/pic2079855.jpg)
The South Shall Rise Again: If I remember correctly I was in the process of circle strafing when I took this picture and had reached the point where I had to get moving again.
I see three approaches to eliminate this exploitive use of the simplicity of the zombie movement rules:
1) Make the zombies faster, but that would very likely make the game way too hard if played in the (most likely) intended non-circle strafing way.
2) Make the zombies furthest from you move randomly so that some of them would likely end up on the edges of the board and thus stopping the rather crucial circle part of the circle strafing. Alternately they could be made to move towards the edge of the board, but that would likely also work out badly with the intended way to play the game and might allow kiting.
3) Adapt the terrain on the edges of the board to slow down the circle strafing player enough that he can’t pull off the strategy. This wouldn’t require much change, since the player never gets much ahead of the zombies.
Before we go on, please let me reiterate that this discussion is dependent on me not playing a rule wrong that allows me to pull off the strategy.
Exploitable behavior: Enforced action sequences
In my previous post, I wrote about how forcing a bot to follow the same sequence of actions to achieve it goals as a human play must perform could lead to degenerate behavior. In my next example, we shall see how it also can lead to exploitable behavior.
When making our Automa for Gaia Project we wanted the Automa to follow the 2-step action sequence of building a mine on a new planet and then later upgrade the mine to another structure. We felt that forcing the Automa to follow this sequence was required to mimic an important interaction in the game (allowing the player to move his power tokens), which is why we did this.
The 2-step sequence was exploitable, because the human player would sometimes be able to cut off the Automa so that it often couldn’t place new mines. But since it just drew actions in random order it would try to place mines anyway and thus waste actions, which is a severe penalty in Gaia Project and it’s something that a human player wouldn’t (and couldn’t) do. He’d do another action instead.
As an astute reader you’ll have noticed that this is the exact same problem that I talked about in Tiny Epic Galaxies (TEG) with the difference being that this time the player could exploit the oblivious behavior of the bot.
Not only was the problem the same, the TEG fix also fixed our problem. In the TEG fix a colonize action without a colonization ship would be turned into a construct colonization ship action and for the Gaia Automa we turned impossible mine building actions into upgrade actions and so the problem was solved.:strip_icc()/pic3972094.jpg)
Losing by 1 VP to the Gaia Automa. Image credit: Theilian.
Detecting degenerate and exploitable behavior
In this post and the previous one I’ve spent more than 4000 words on examples of how bot rules that are too simple can cause trouble and it’ a very real issue that’s hard to deal with. One of the things that makes this hard is that degenerate and exploitable behavior can be hard to detect.
There’s probably a full series of blog posts in that topic, but I’m not sure I’m the right person to write them, so for now I’ll just spend a few not very useful paragraphs.
The main piece of advice is to consider extreme and weird strategies. A human opponent would quickly take advantage of your bad strategies and so they would be of no use to you, but a cardboard bot is not intelligent. Its rule system is often based on the assumption that the player plays intelligently and so it’s extreme strategies that are most likely to find an edge case in the bot’s behavioral rules that makes it implode.
For most games you’ll be able to dream up a zillion weird strategies in no time and trying out all of them is impossible, so it’s a great help to have some idea of where to start.
The simple, but hard to use, advice here is to look at each of the bot’s mechanics while ignoring the design intent of the mechanic and instead look at it objectively. Each mechanic takes the current game state as input and produces an alteration of the game state.
When looking at each mechanic and its input in isolation you can likely reduce that zillion possible strategies that you should try out to a manageable number. Basically, you’re going from considering all combinations of a full game worth of inputs to all mechanics to instead considering a handful of inputs for each mechanic taken one at a time.
I’m oversimplifying here, though, since in most cases you’ll need to consider at least a couple of mechanics together to produce degenerate of exploitable behavior.
Apart from the enormous number possible (and impossible) combinations it’s also hard, because you’re going against your intuition, which tells you to play the game as intended and going against your intuition is hard. One way to make this easier is to completely ignore that you’re playing a game and instead look at the bot rules as a puzzle. You solve the puzzle by making the rules produce weird results.
No matter how many helpful techniques you apply it’s going to be an uphill battle to spot degenerate and exploitable behavior in your own design, since you know how you intend the game to be played and so you’ll fall into the trap of playing that way when you test.
This is the same as people having a hard time proofreading their own text, because they know what it’s supposed to say and so miss what it actually says.
This is of course one of the reasons that you need lots of external playtesters, since they don’t know as well as you what your intention was and so they’re more likely to spot errors than you are. Most people, though, are wired to play the game instead of looking for weird edge case bugs and so playtesters who has a knack for seeing the rules as they are, not as they’re intended, and has a knack for finding the edge cases are rare and immensely valuable.
As the saying goes among tech geeks: There’s a XKCD for that.
That’s it – for now
This post and the one before it are siblings dealing with two different aspects of the same issue: Bots that are misbehaving because they’re too simple for the behavior they’re mimicking. The siblings are the children of another small blog post series that I’m writing about my Automa Approach for making bots.
In that mini-series I’ll put the topics discussed here into the larger context from which they came.
Thematic Solitaires for the Spare Time Challenged
A blog about solitaire games and how to design them.
I'm your host, Morten, co-designer of solo modes for Scythe, Gaia Project, Wingspan, Glen More II, and others.
- [+] Dice rolls
