,(((&,*  Tainan, Taiwan August 31, 2015 – September 2, 2015
Mining game logs to create a playbook for unit AIs
Daniel Wehr
Department of Computer Science
University of Calgary
Calgary, AB, Canada, T2N 1N4
Email: dkwehr@ucalgary.ca
Abstract—We present a method for mining game logs for
plays, sequences of actions for a group of units achieving an
objective with a high likelihood and in many logs. The mining
moves through a log backwards, identifying states that achieve the
objective and taking this state and certain surrounding ones as a
play candidate. After filtering out irrelevant information and too
costly candidates, we cluster similar candidates and abstract the
candidates in large enough clusters into a play. We applied these
general ideas to the game Battle for Wesnoth and our evaluation
showed that we are able to consistently mine successful plays,
some of which are also often applied in logs that were not used
for the mining.
I. I NTRODUCTION
Analyzing logs of systems that either record the interac-
tions of the components of the system or the interactions of
the system with users and other systems is not just useful
for debugging of such systems. Analyzing the internal in-
teractions can identify system performance optimizations by,
for example, identifying bottlenecks or unintended interaction
sequences. Analyzing the interactions with the outside can
identify attempts to compromise the system but also the usage
intentions and preferences of human users. For nearly all the
intended analyses large or multiple logs are needed to be
sure enough about identified patterns which makes the use of
automated learning or mining necessary.
In the area of games we have also already seen approaches
to mine game logs, for example to find clusters of player be-
havior (see [3]) or to identify aim robots (see, for example, [2]).
While these approaches concentrate on the outside interactions
of a game, in this paper we present an approach for mining
game logs that aims at the internal interactions of game units
with the goal of improving their cooperation.
More precisely, we aim at finding what we call plays,
sequences of actions for a group of units (or NPCs) that accom-
plish a given directive with a high probability of success and a
high probability of being triggered in a single game (preferably
several times). Examples of plays are action sequences by a
group of game units that kill a particular type of enemy in a
particular terrain, sequences that result in taking a city under
given circumstances, or a particular play from a particular
situation in a team sports game that results in a score. [1]
showed that adding plays to the choices for an AI can lead to
substantial improvements when trying to learn a way to beat
a particular other AI.
Our proposed method for learning plays from game logs
works in several phases. In the first phase, we scan a log
‹,((( 391
Jörg Denzinger
Department of Computer Science
University of Calgary
Calgary, AB, Canada, T2N 1N4
Email: denzinge@cpsc.ucalgary.ca
backwards for occurrences of the intended directive and store
the information of the log at that time, the information in the
following state (in the game) and the information of a given
number of game states before the found state. This constitutes
a play candidate. In the second phase, we eliminate from a
play candidate all irrelevant information, while the third phase
filters out candidates that achieve the directive at too high a
cost. The following phases look at the whole set of candidates
that made it through the first three phases. Phase four clusters
the plays according to a game specific similarity function
and, finally, phase five generalizes the candidate plays in each
cluster into a play for the game.
Since nearly every phase requires specific information
about the particular game the logs are coming from, we
present in this paper the method applied to the game Battle
for Wesnoth (see [9]). Our experiments, using data mining
evaluation techniques, show that we are consistently able to
find plays that are occuring in many logs and that are often
successful even for a harsh definition of ”many” and ”often”.
This paper is organized as follows: After this introduction,
in Section II we present a short description of the game
Battle for Wesnoth and a unit/agent oriented view of the game
inspired by [6]. Section III first provides a definition for what
we consider a play and then presents the different phases of
mining plays from game logs. In Section IV we evaluate our
method by mining plays from a set of training logs and then
checking a set of test logs for instantiations of the mined plays.
Section V discusses related work and Section VI provides
concluding remarks and ideas for future work.
II. BASICS
In this section, we will first present a basic description
of Battle for Wesnoth and then present a detailed view on
the game from the perspective of an individual unit (agent),
inspired by [6], which will be the basis for the plays we want
to mine.
A. Battle for Wesnoth
Battle for Wesnoth is a turn based strategy game where
the player controls an army of units. Additionally, the game
includes an economic component that allows for the creation
of new units during a game, but we are not using this aspect
of the game in this work. We are focusing on the two player
local scenario mode where normally a human player battles an
AI player, but we have AI players battle other AI players for
the creation of our game logs (see Section IV).
 ,(((&,*  Tainan, Taiwan
Battle for Wesnoth is played on a map consisting of
hexagonal tiles. Each tile is a composite that can consist of
terrain types such as rivers, forests, and mountains or structural
areas such as bridges, castles, and villages. Any unit entering
a tile ”pays” a movement cost which is based both on the
type of terrain and the type of unit. The tile a unit is on also
provides offensive and defensive bonuses, based on the type
of unit. For example, Elves have a defensive bonus for being
in forest tiles. There is also a day/night cycle that provides
advantages and disadvantages to different units. Finally, tiles
with a village on it provide healing to a unit that rests on it.
Each player in a Battle for Wesnoth game controls an army
consisting of one leader unit and many follower units. A unit
can either move or attack an enemy unit or do nothing. Each
unit has an allotted number of movement points which it uses
to move across the tiles. Because different tiles have different
movement costs the distance that a unit can travel often varies.
If a unit attacks another unit it forfeits all of its movement
points and cannot take any further actions that turn, therefore
if a unit needs to be moved to a different tile it must perform
the move action prior to performing an attack action.
A move action from one tile to another is not guaranteed to
succeed because the unit can get ambushed by stealthy enemy
units in which case the unit is stopped at the ambush tile. An
attack action is not guaranteed to succeed because the success
rate is determined by the type of weapon used, the tile the
enemy unit is on, the tile the attacking unit is on, and the
day/night cycle, all of which combine to form an attack success
percentage ranging from 40% to 80%. Additionally, under
certain circumstances an attacked unit can retaliate wounding
or killing the attacker. All of this makes Battle for Wesnoth
non-deterministic in that actions taken by a unit have a chance
to fail and may not change the game state at all.
A game of Battle for Wesnoth consists of a sequence of
turns. Each turn, a player may act for their side while the
opponent waits. These roles are reversed when the acting
player indicates the turn is over. A player wins the game by
defeating the opponent’s leader unit. In the next subsection,
we will provide a more formal view on Battle for Wesnoth
and the units.
B. An agent-oriented view of Battle for Wesnoth
In order to be useful, plays need to capture the key
properties of the game states that are responsible for achieving
the intended objective and abstract away other properties. In
addition, we would like plays to be usable both for an AI that
controls all units and for AIs that control only a single unit
(as proposed in [6]). Since given plays for all single units it is
easy for a central AI to control all these units, we will focus in
this paper on representing plays from the perspective of a unit.
For both, the key properties and the unit (agent) perspective,
the concept of observations from [6] is a good starting point.
Seeing a game unit as an agent means that a unit Ag is
defined as Ag = (Sit,Act,Dat,fAg ), where Act is the set of
actions it can perform1 , Dat is the set of possible value com-
binations of its internal data areas and fAg : Sit × Dat → Act
1 Since Battle for Wesnoth can have a unit perform several moves and/or an
attack in a turn, we assume that Act contains also all such combinations as
individual actions.
392
August 31, 2015 – September 2, 2015
is its decision function. Of particular interest with respect to
plays is the set Sit of possible situations Ag can be in, which
is essentially Ag’s view of a game state (although, naturally,
there is a data area in Dat that would store plays and fAg
needs to make use of stored plays). [6] proposed to describe
an element sit ∈ Sit as a subset of so-called observations
Obs, sit ⊆ Obs, that are simple predicates describing a game
state from the perspective of the agent, more precisely from
the perspective of the tile the agent occupies and other tiles
of importance to the agent. An element of Obs is part of the
current situation of an agent if this predicate is true in this
situation.
We subdivided Obs into three disjunctive subsets Obs =
Obsown ∪ Obsteam ∪ Obsenemy that contain the predicates
dealing with an agent itself, the other agents in the team
of the agent and the enemy agents/units. As mentioned
above, Obs and naturally also the three subsets represent
abstractions, which is rather obvious due to the fact that
there are no predicates dealing with properties of the map
of tiles. In fact, Obsown deals purely with the health of
the agent, containing four predicates: HasFullHP, HasLt75HP,
HasMoreThanHalfHP and HasLessThanQuarterHP with the
obvious meanings. Obsteam contains predicates indicating that
a tile is adjacent to a friendly unit (AdjacentToFriendly), to
the leader (AdjToFriendlyLeader), to a damaged friendly unit
(AdjacentFriendlyIsHurt) or to a healer (AdjToHealer). The set
Obsenemy provides information like a tile having the enemy
leader on it (HasEnLeader), or a unit that cannot retaliate
(EnCan’tRetaliate). The rather complex boni and penalties due
to terrain are abstracted to ”being disadvantaged” (EnIsDisad-
vantaged). There are additionally predicates about the health
of an enemy unit, similar to the ones for friendly units and
also similar predicates to Obsteam about adjacent tiles.
Given a game state representation s containing the po-
sitions of all agents and their health together with the
game map, a situation description using Obs for each
agent can be easily computed using the tile the agent
is occupying in s and all tiles visible/reachable by it
within the turn. A log for a game is then a sequence
s1 , Acv11 , s2 , Acv12 , s3 , ..., s2i−1 , Acvi1 , s2i , Acvi2 , ... of game
states si and action vectors Acvil = (al1,i , ..., alml ,i ) with
alj,i ∈ Actlj for agent Agjl , with l indicating the team Agjl
belongs to (in our case l ∈ {1, 2} and ml indicating the number
of units in each team).
III. M INING LOGS FROM BATTLE FOR W ESNOTH
In this section, we will first formally define what a play
is and then go through the steps we used to mine such plays
from logs from Battle for Wesnoth.
A. Plays formally
The goal of this research is the mining of game logs of
Battle for Wesnoth for plays, which are essentially sequences
of actions for a group of agents that should achieve a
given directive, in our case killing an enemy. Obviously, a
play needs to be triggered and, given the non-deterministic
elements of the game, a play can fail at any point while it is
performed. This leads us to the following definition of a play
P lay:
 ,(((&,*  Tainan, Taiwan
P lay = (Roles, ActionT r, T rigger).
Here, Roles = (r1 , ..., rk ) is a vector of placeholders for
agents that needs to be instantiated by agents from a concrete
game state s. ActionT r is a tree structure, where a node has
the form
(((r1 , cond1 , a1 ), ..., (rk , condk , ak )), {subtr1 , ..., subtro }).
The ai s are actions (that an agent fulfilling the role ri has to
be able to perform, see later) and the condi s are conditions
that have to be fulfilled in the agent’s (fulfilling ri ) current
situation. This means that a condi is a subset of Obs,
respectively an extension of Obs that allows us to also
describe health differences between agents (RelHDiff) in
addition to the ”concrete” health predicates mentioned before.
A subtrj is, as the name suggests, a sub-tree of ActionT r
describing the actions of the agents for the next turns. By
having several sub-trees, a play can describe several variants
in reaction to what the enemy units are doing. We consider
the ”length” of a play to be the number of turns an agent
would require to perform their role actions, for a path through
ActionTr.
T rigger is a collection of conditions that need to be
fulfilled for a play to be enacted. For this, we first need a
function fras that provides for each role ri ∈ Roles an actual
agent Agi (note that these assignments will include one agent
from the other team, the target of the play). For i = j we
require fras (ri ) = fras (rj ). Determining fras is part of the
trigger evaluation and after finding fras , we have to test all
of the conditions condi in the root node of ActionT r, if
they are true under fras . Additionally, T rigger has to contain
additional conditions on fras out of a set Obsrole that describe
required properties of the agent assigned to a role, like the type
of agent (for example, being an archer, or being one of a set
of different types).
With this, determining that a play can be activated comes
down to finding an fras that fulfills T rigger. And enacting
the play is done by following a path through ActionT r where
the conditions for the agents assigned by fras to the roles are
fulfilled in the game state reached when a node is reached and
each agent performs the prescribed action from the node.
B. Creating a play candidate
Given a game log s1 , Acv11 , s2 , Acv12 , s3 , ..., s2i−1 , Acvi1 ,
s2i , Acvi2 , ..., play candidates are identified by going through
the log backwards and constructing a candidate out of every
game state in which an agent of either team was killed and the
states (and action vectors) around this state. More precisely, if
si is such a game state, the initial play candidate will consist
of the lmax game states before si and the game state si+1
and all action vectors between these states, i.e.
l1 l2
si−lmax , Acvi−lmax , si−lmax+1 , Acvi−lmax+1 , ..., si ,
l2
Acvi , si+1
Note that the possible play created out of this candidate will
use the actions of agents from the team that is l1 , since this
team was responsible for the killed agent (from l2 ). Due to
that, lmax should be an even number, since the first state
in a candidate as defined above would not be of interest
otherwise (and we accounted already for that by indicating
l1
that Acvi−lmax is taken by the agents in l1 ).
393
August 31, 2015 – September 2, 2015
C. Eliminating irrelevant information
At this stage, the states and action vectors of a play
candidate contain information about all agents of the teams.
But usually only a few of the agents of the team that managed
the kill really contribute to this outcome, and naturally only
the actions and features of those agents should be represented
in a play. Therefore, in this step we first have to identify the
agents that are relevant.
We start by putting all agents that were killed in si (i.e.
all agents that were alive in si but not in si+1 ) into the set
of relevant agents. In all plays we mined there was only one
such agent. All agents that performed an attack action on the
killed agent naturally are also relevant. We will refer to the
team of those agents as the attacker team or the friendly team
and to the other team as the enemy. All agents that in any of
the states of the candidate plan (except for si+1 ) are adjacent
to any of the relevant agents so far are also relevant. We also
consider all agents relevant that in any of the states of the
candidate (again, except for si+1 ) are within a given distance
reldist of any of the killed agents. This distance is measured
by considering the shortest path length (in tiles) between the
agents. In our experiments, we used reldist = 3. Finally, we
also consider any friendly agent as relevant that in one state
of the candidate play moved out of a tile that a unit that is
already relevant moved onto in the same turn.
Given all relevant agents as defined above, we now elim-
inate from each si all agents that are not relevant (creating
states si ∗). We also create out of all Acvil new action vectors
for the relevant agents only (Acvil ∗).
D. Eliminating too costly candidates
So far, a play candidate only has established that the
actions by the attacker team have resulted in killing a unit
of the enemy. While this is part of our goal, a play achiev-
ing that while loosing a lot of team members from the
attacker team or just while having one or several of the
team members near death is not really a good play and
not something we want to use. To filter out the costly play
candidates we define the utility util of a play candidate plc =
s1 ∗, Acv1l1 ∗, ..., slmax ∗, Acvlmax
l2
∗, slmax+1 ∗ as follows2 :
lmax/2
util(plc) = j=1 ( enDg(s2j ∗, s2j−1 ∗) × wenDg −
f rDg(s2j+1 ∗, s2j ∗) × wf rDg +
enLDg(s2j ∗, s2j−1 ∗) × wenLDg −
f rLDg(s2j+1 ∗, s2j ∗) × wf rLDg −
enP H(s2j ∗) × wenP H +
f rP H(s2j−1 ∗) × wf rP H +
enD(s2j ∗) × wenD −
f rD(s2j−1 ∗) × wf rD +
enLDs2j ∗) × wenLD −
f rLD(s2j−1 ∗) × wf rLD )
In the formula above, the function enDg(s, s ) computes the
damage taken by the relevant attacked agents (the enemy)
between state s and s (i.e. during the turn of the attacking
team). f rDg(s, s ) is doing the same for the relevant attacking
2 We renumbered states to start with index 1 for easier readability.
 ,(((&,*  Tainan, Taiwan
agents. enLDg(s, s ) and f rLDg(s, s ) compute the damages
to enemy and friendly leader (if they are relevant). enP H(s)
and f rP H(s) compute the overall potential healing enemy,
resp. friendly, units get after state s. Finally, enD(s), f rD(s),
enLD(s) and f rLD(s) compute the number of dead enemy
agents, dead friendly agents, dead enemy leaders and dead
friendly leaders (from the set of relevant agents and naturally
with a maximum of 1 for the leaders) in state s. Please note
that by having slmax+1 ∗ included, we are discouraging suicide
attacks by attackers to kill a target enemy.
All of the w components in the formula are weight factors
allowing us to manipulate the influence its corresponding func-
tion component has. For our experiments we used wenDg =
wf rDg = 1, wenLDg = wf rLDg = 3, wenP H = wf rP H =
0.8, wenD = wf rD = 10 and wenLD = wf rLD = 1000. Due
to this weighting scheme, a play candidate with a positive
utility passed the filter. After this filtering step, information
about the states resulting from an enemy turn and enemy
actions are not necessary anymore and they are discarded from
the play candidates for the next phases.
E. Clustering play candidates
Our mining approach has now reached the stage where
we have a set of candidate plays {plc1 , ..., plcp } of sufficient
utility. But it is unclear, if these candidate plays can be used
in enough games or often enough in some single games to
be useful. The solution to this problem cannot be achieved
by looking at individual candidates, but it is within the set of
candidates, since it contains all candidates that can be extracted
from the given logs. Following the idea from [8] to identify
recurring tasks, we use clustering of the candidate plays to
detect groups of similar candidates big enough to be considered
useful.
Before we perform the main clustering, we split the set of
candidate plays into several sets in a pre-clustering step, using
criteria where different values are known to be incompatible
to ensure that candidates that differ in these values always end
up in different clusters. These criteria are the enemy leader
being a target of the play or not and the number of attacker
agents. We then perform the following clustering in each of
these sets (and create plays out of all the clusters large enough
in each set).
A key component of any clustering algorithm is the similar-
ity (or distance) function between the elements to be clustered.
Here, candidate plays present a little bit of a challenge due to
what they contain. If we look at two states (which has to be at
the core of such a similarity function), then there is an obvious
need to determine an assignment of the agents of each state to
the agents of the other state and after such an assignment is
done, the similarity does not only have to look at the formation
of the agents (resp. the differences there), but also at properties
of the agents, like type and health. With regard to a property
like health, we have to deal with the fact that, for the purpose
of fighting with other units, there is some anti-symmetry here.
If in a state s a unit Agi has more than 50 percent of its health
remaining and in the state s the corresponding unit Agi has 25
percent of its health, then, for the purpose of a battle, the unit
Agi should be considered somewhat similar to Agi , but not
vice versa. And on the formation side, if corresponding units
394
August 31, 2015 – September 2, 2015
in the two states have different move distances from each other
and the target unit then it is very unlikely that the same actions
applied in each state will result in the same outcome in the two
follow-up states. So, states with such difference in formation
should not be considered similar at all.
Our solution to all these problems is to first compute a
similarity matrix for the start states of all the play candidates
in the following manner. If si is the start state of play candidate
plci and sj for plcj , then for each of the different assignments
assign of agents in si to agents in sj (within the different
teams, naturally), we first compute the move distances between
all agents in a state. If there are any differences in agent
distances between the two states, then we consider them not
comparable. Otherwise, we compute the similarity sima as
sima (si , sj , assign) = typeM is(si , sj , assign) × wtype +
healthM is(si , sj , assign) × whealth
where typeM is(si , sj , assign) is the number of agents in si
for which assign did not assign an agent in sj of the same
type and healthM is(si , sj , assign) is computed by putting
each agent into a health category (more than 75 percent, more
than 50 percent, more than 25 percent, less than 25 percent,
but only one of these categories can be used) and summing up
over all agents the following penalty values: if the unit in si has
a higher category than the assigned unit in sj , then the penalty
is 0, otherwise it is the number of categories the unit in si is
below the category of the unit in sj (so, for example, if the
unit in si is in the more than 25 percent category and the unit
in sj is in the more than 75 percent category, then the penalty
is 2). As usual, the ws are weights and in our experiments
we set them as wtype = 2 and whealth = 1. The similarity
sim of si to sj sim(si , sj ) is then the minimal value over all
possible assignments. We also record the particular assignment
that was used for computing this value, since we will use this
assignment in all future computations involving the two play
candidates.
The similarity matrix allows us already to identify candi-
date plays that are not similar at all to any candidates and
these plays will be filtered out. The remaining candidates are
then clustered using the PAM algorithm (see [5]) and the
similarity matrix. PAM is very similar to the well-known k-
means algorithm and has similar limitations. PAM is given
a number k of clusters and then randomly selects k candidate
plays as the so-called medoid of a cluster. Then each remaining
candidate play is assigned to the cluster it is most similar to
the medoid using the similarity matrix and the first state in the
play. For each of the clusters, we sum up the similarity values
of each element to the medoid as this cluster’s ”cost”. We then
try to improve (i.e reduce) this cost by trying to swap one
medoid with another play candidate in the cluster, recalculate
clusters and cost and go through all possible swaps in all
clusters to find the best swap, i.e. the one that reduces the cost
the most. If we find such a reduction, we then make this swap
permanent and use this new group of clusters as a starting point
for the improvement, again. We repeat this for a given number
of iterations (in our experiments 1000) or until no improvement
is found. This is one run of the PAM algorithm and due to
the initial randomness we restart the algorithm several times
(50 in our experiments). Since we also do not know what the
best value k is, we do the above for the different k under
consideration (between 1 and 15 in our experiments).
 ,(((&,*  Tainan, Taiwan
The above procedure leaves us with quite a number of
different partionings of the candidate plays into clusters. Since
we do not want to have a candidate play in several clusters,
we need to determine which of these partionings (and con-
sequently clusters) we want to use in the next phase. There
are several ways to address this in the literature and we have
chosen to use the partioning with the best Silhouette value (see
[7]) and to select all clusters in this best partitioning of a size
of at least minClSize for going forward to the final step of
our method. In our experiments, we used minClSize = 5.
Please note that while we have so far only used the first state
in each play, the action vectors and other states will be used
in the final step.
F. Generalizing clusters into plays
As stated above, the set of clusters {Cl1 , ..., Clt } resulting
from the above phase of our method is used to create a play
out of each Cli . The root of the ActionT r component of the
play P layi for Cli is constructed by using the first state of the
medoid and abstracting this state into a set of conditions cond
for each of the agents of the friendly team by including all
observations from Obs that are true in this state, resp. the part
of it that is observable by the agent. The same observations also
go into the trigger T rigger (as mentioned before), but we add
to it the appropriate observations from the role observations
(Obsrole ) and we report the observations around the health of
the various agents in the following way.
If the health observation for the target is the same in every
candidate of the cluster, we use this observation for the target
and add for all other agents predicates describing the health
of this agent relative to the target’s health. For example, if the
target has more than 50 percent health and the other agent has
more than 75 percent, then the predicate for this agent will be
RelHDiff(+1). If the other agent has less than 25 percent, then
it will have RelHDiff(-2) added as health observation. If the
health observation for the target varies in the candidates, we
first compute the relative health differences between agents
within a candidate as described above and then we put into
the play the highest health observation for the target and for
each other agent the smallest relative distance to the target in
any of the candidates. The action for each role in the root of
ActionT r is determined as the action taken by most of the
corresponding agents in the cluster.
To complete ActionT r, we recursively go over the fol-
lowing steps until we have reached the last state in the play
candidates. Given a cluster of play candidates that has created
a node in ActionT r that has no subtrees, yet, we create a set
of clusters of these candidates by applying the PAM algorithm
we described in the last subsection. Corresponding agents in
the states of two candidates are determined by the assignment
computed for these two candidates when creating the similarity
matrix for the first states of these candidate plays. There is
no filtering out of states that are incompatible with all other
candidates, these states simply form their own cluster (and
consequently node in ActionT r). With regard to k-values, we
set it in PAM from 1 to the cluster size of the cluster we are
sub-partitioning. Each of the clusters of the best partitioning
out of the application of PAM is used to create the root node
of a new subtree (of the node we are working on) and the other
395
August 31, 2015 – September 2, 2015
components of this root of a subtree are created as described
for the root node of the whole play.
IV. E VALUATION
In this section, we first present the set-up of our experi-
ments with the method presented in the last section and then
present the results of these experiments. We will first take
a look at the overall numbers of plays identified in various
mining runs and the successes of these plays in logs that were
not used to create them and then we will look at some of the
found plays in more detail.
A. Set-up of experiments
While Battle for Wesnoth has already facilities to create
game logs and there are even some logs available on the
Internet, what these logs store is not enough for our purpose.
Therefore we needed to create game logs with all necessary
information on our own, which would have been a rather
tedious process if we had not had the system from [6] available,
which allowed us to learn a wide variety of unit AIs that we
could combine to create players playing against each other.
We used different combinations of the learned unit AIs to play
games against each other and the build-in game AI on the The
Freelands map, resulting in 2000 logs of games.
To evaluate our mining for plays, an experiment consisted
of randomly selecting half of the game logs to apply our
method to (training examples) and then we checked the other
half of logs (test examples) for game states fulfilling the
triggers of the found plays. For every such state we then
checked what happened in the log against the triggered play
and counted the play as successfully applied, if the targeted
enemy was killed while the attacker units in the play where
following a path through ActionT r (or immediately after
going through the whole path). Otherwise, we consider this
an unsuccessful trigger of the play. To get an idea of how
reliable our mining approach is, we performed 10 of these
experiments, each for two different values of lmax/2, namely
2 and 3.
B. Mining plays: the numbers
While it naturally would be best of we could provide
detailed information on each of the plays mined in each of
the experiments, we do not have the space for doing this. As
Table I shows, in the experiments mining plays of length 2 we
have on average over 32 plays and while increasing the length
to 3 reduces the number of plays, it is still over 23 on average.
We will therefore present statistical results of our evaluations
on the level of experiments, providing average, maximum and
minimum numbers of plays.
TABLE I. N UMBER OF PLAYS MINED ( ON AVERAGE , MIN AND MAX ;
PLAYS TARGETING LEADER IN PARENTHESES )
lmax/2 2 3
avg. 32.8 (13) 23.1 (8.3)
max. 36 (15) 27 (10)
min. 27 (9) 18 (5)
Our goal was to mine plays that are often applicable in
games and that are often successful in killing an enemy.
Table II presents the number of plays that could have been
 ,(((&,*  Tainan, Taiwan
activated in the set of test logs on average once or more than
once per log. While the reported numbers are substantially
smaller than the number of plays (as was expected given the
fact that we used quite a number of different AI players in
creating the logs), we have more than a third of all plays
often applicable. This becomes even better, when we take into
account that plays that target the enemy leader are unlikely to
be activated more than once per log. In fact, in Table I the
numbers in parentheses indicate the number of mined plays
that target the enemy leader and with this we have more
than half of the non-leader plays being often applicable. The
highest number of average applications of a play per log in all
experiments was over 23, with all but one experiment having
at least one play that was applicable in the test logs more than
10 times per log.
TABLE II. N UMBER OF PLAYS MINED ACTIVATED MORE THAN ONCE
PER LOG IN TEST SET ( ON AVERAGE , MIN AND MAX )
lmax/2 2 3
avg. 13.5 10.1
max. 17 12
min. 10 8
As for the success of the mined plays, Table III shows the
number of plays that, in the test logs, can be ”played” through
and are successful in killing the target in more than half of
the times they would be triggered. Naturally, the longer a play
is the more likely it is that the players producing the logs
would use different actions for their units, which then results
in different outcomes. The drop in the numbers in Table III
from length 2 to length 3 reflects that. But even for a length
of 3 actions we have at least 2 plays in each experiment that
are rather successful.
TABLE III. N UMBER OF PLAYS MINED WITH MORE THAN 50 PERCENT
SUCCESS IN EVALUATION ( ON AVERAGE , MIN AND MAX )
lmax/2 2 3
avg. 10.5 3.4
max. 13 5 of fighter). The target has to be a leader with a health of 100
min. 8 2
Finally, Table IV reports the number of plays that both were
”activated” once or more on average in the test logs and that
were successful more than half of the time. As this table shows,
each of the mining experiments produced at least one such
play, with at least 3 for the experiments mining shorter plays.
If we lower the requirements to 0.1 activations on average and
25 percent success, we get the numbers in in Table V, with
a minimum of 7 such plays of length 2 and 2 of length 3.
The averages over all experiments show that one third of the
mined plays of length 2 could be considered often applicable
and successful and over one fifth of the plays of length 3 using
these weaker definitions.
TABLE IV. N UMBER OF PLAYS MINED ACTIVATED MORE THAN ONCE
PER LOG AND WITH MORE THAN 50 PERCENT SUCCESS IN EVALUATION
( ON AVERAGE , MIN AND MAX )
lmax/2 2 3
avg. 5 2.2
max. 7 3
min. 3 1
Overall, by just mining 1000 game logs, our method was
able to mine often applicable and often successful plays even
396
August 31, 2015 – September 2, 2015
TABLE V. N UMBER OF PLAYS MINED ACTIVATED IN 10 PERCENT OF
LOGS WITH MORE THAN 25 PERCENT SUCCESS ( ON AVERAGE , MIN AND
MAX )
lmax/2 2 3
avg. 11.3 4.9
max. 14 7
min. 7 2
under rather harsh definitions of these terms (given the non-
determinism of the game). While, especially due to the tree
structure of our plays, the plays found in the different exper-
iments most of the time were not identical, in our subjective
judgment there are at least some similarities. This is another
reason why we presented our data on the experiment level.
C. Mining plays: selected plays
In this section, we will take a closer look at two of the
mined plays. Our first play example is a play that attempts
to kill the enemy leader. In our evaluations, its trigger was
matched in a little over 30 percent of the test logs. And then it
was successful in killing the leader 73.4 percent of the cases,
which naturally means that the whole game was won. In short,
the play is best described as killing a lone leader, which, as
the pictures in Figures 1 and 2 show, can occur if the leader
stays in the castle.
The initial conditions of the play are that the first friendly
unit is the leader adjacent to the two other friendlies with a
relative health to the target that is -1 (or better). The second
unit has to be an archer or a shaman that is one move away
from the third unit and the target. It also has to have a relative
health of at least -3. The third unit has to be a shaman or fighter
fulfilling the location requirements indicated in the conditions
for the other two units and having a relative health of at least
-3. Our instantiation in Figure 1 has fras assign as the second
unit an archer and as the third unit a warrior (which is a type
percent at the most.
The actions of the friendly units have them move to the
target and attack it, with the second and third unit having to end
up being adjacent to the first unit. These moves are indicated
by the red arrows in the figures for this concrete instantiation.
In our instantiation, the enemy’s counterattack kills the archer.
Its own actions are to move where the archer died and to attack
the friendly leader (but not doing a lot of damage).
Our play has a subtree (a node really) that has as conditions
that the first unit is adjacent to target and the third unit and
that its relative health is +1. The third unit must be adjacent
to the first and one move away from the target, with a relative
health of 0 and it must be a fighter. The target must have a
health of under 50 percent.
The first unit’s actions are to move adjacent to the target
and then to attack it, while the third unit has to move adjacent
to both the first unit and the target and then attack the target.
Figure 2 shows this for our instantiation from one of the test
logs. Note that in this instantiation the first unit is already
adjacent to the target.
This example shows that our mining allows for creating
plays that make ”useful” sacrifices. Trading a non-leader unit
 ,(((&,*  Tainan, Taiwan
for killing the enemy leader is definitely useful. We also see the
possibility of strengthening of conditions, especially regarding
the relative health of the units, that can be used to realize that
the play might not work as planned, which is naturally very
important in this play, given that one of the friendly units is
the leader.
Figures 3 to 5 show one instantiation of our second exam-
ple play of length 3 with 2 roles to fulfill. This particular play
was on average 7.6 times per log applicable in our evaluations,
with a success percentage of 35. In short, this play is best
described as hunting lone enemies.
The play has two friendly roles and the trigger conditions
require that those two friendly units are not the leader and that
they are at least as healthy as the target. The first friendly unit
must be two moves away from the target, the second unit 3
moves and both of them must be one move away from each
other. Figure 3 shows an instantiation of this where the fras
Fig. 1. Killing a lone leader: approach actions
Fig. 2. Killing a lone leader: going for the kill
397
August 31, 2015 – September 2, 2015
assigns the first unit to a shaman (upper left) and the second
unit to a fighter (lower right). The target unit is not visible,
but it is located northwest from these units. The play requires
the second unit to move adjacent to the initial position of the
first unit at a spot that is closer to the target than the first unit
is. The first unit has to move between the new position of the
second unit and the target.
The subtree of the play that was matched by the depicted
instantiation strengthened the conditions for the involved units,
now requiring that the first unit is a shaman and the second one
a fighter. It also requires that the target is a fighter and that the
friendly units are at least as healthy as this target. Additionally,
the first unit has to be adjacent to the target and the second
unit one move away from it. Note that this required that the
target did move towards the friendly units in its previous turn,
which was the case in the instantiation depicted in Figure 4.
As this figure shows, the actions of the play have unit 2 move
adjacent to the target and the other friendly unit and then attack
the target. The first unit has to move away from the target but
stay adjacent to the second unit (which will result in the first
unit being healed in the next turn).
The next node in the play requires the two friendly units
to be adjacent to each other and one move away from the
target (as seen in Figure 5). It also requires that the first unit’s
relative health to the target is +2 and the second one’s is +1.
The target itself must be below 50 percent of maximum health.
The actions are essentially a repeat of the previous turn, with
the second unit moving towards the target and attacking it.
The first unit moves again so that it is one move away from
the target but adjacent to the other friendly unit. This should
result in killing the target (as it did in the instantiation).
This play and its instantiation highlight several features
of our mining method, again. The level of abstraction that we
used for triggering a play really focuses on the requirements for
the actions that form the play and allow for different outcomes
of these actions (and the actions of the enemy unit). While the
players in the test logs naturally are not aware of plays and
therefore can not ”abandon” a play if the conditions of none
of the subtree roots are met, the fact that these conditions can
be more strict than the initial trigger should allow, again, for
exactly such a cancelling of a play in applications that are built
with the concept of plays in mind.
V. R ELATED W ORK
From a mining perspective, our method aims at finding
sequences of events in data that are both occuring sufficiently
often and have a high utility. There are only very few works
in that area and [10] is currently the leading method known.
But [10] does not deal with events created by groups of agents
(or complex scenarios with states). It also allows for having
unrelated events in between events of a sequence (which we
do not do, which made our task a little bit easier). On the
other side, we include in our plays the possibility of several
different follow-up actions, which is also not part of [10].
If we look at data mining in games in general and especially
of game logs, then we see a lot of works in the last few
years and we even have a first overview article with [4].
But, as this overview article shows, the focus on mining of
game logs is on creating information about players and not so
 ,(((&,*  Tainan, Taiwan August 31, 2015 – September 2, 2015

much on information about the game (and our plays represent

information about good move combinations and sequences
of units). An example of this difference can be seen in [3]
which, like us, uses clustering methods but with the purpose
of clustering players of games and detecting player types. This
requires not just abstraction of game states, but an abstraction
of whole games.

VI. C ONCLUSION AND F UTURE W ORK

In this paper, we presented a mining method for plays,
sequences of actions for a group of units intended to achieve
a given directive, out of game logs for the game Battle for
Wesnoth. Our representation of plays allows for executing
them by a central AI, but also by unit AIs. Our method
identifies game state sequences that end with the directive
fulfilled, filters out irrelevant information from these states and
discards sequences that fulfill the directive at too high a cost.
It then clusters similar sequences to identify clusters that are
big enough to represent a play. Our evaluation of the mining
method, using training logs and test logs and experiments Fig. 3. Hunting lone enemies: approach actions
with different sets of these logs, showed that we are able to
find several plays with a high chance of success and often
applicable consistently, even out of a set of logs that was
created using quite a number of (learned AI) players.
While we have a method for mining plays and [1] indicates
that plays (resp. macros that are more simple then our plays)
are very useful, future work will focus on exploring the
usefulness of plays more. [1] focused on testing of AI players,
requiring to find only one way to beat the AI. In contrast, [6]
presented a concept for learning general game behavior and
plays should be even more useful with this regard. We also
intend to look into mining plays for other games.

R EFERENCES
[1] M. Atalla, J. Denzinger, Improving Testing of Multi-Unit Computer
Players for Unwanted Behavior using Coordination Macros, Proc. CIG-
09, Milan, 2009, pp. 355–362.
[2] K.-T. Chen, H.-K. Kenneth Pao, H.-C. Chang, Game bot identification
based on manifold learning, Proc. 7th ACM SIGCOMM WS on
Network and System Support for Games, NetGames, New York, 2008,
pp. 21–26. Fig. 4. Hunting lone enemies: first attack and ensuring healing
[3] A. Drachen, R. Sifa, C. Bauckhage, C. Thurau, Guns, swords and data:
Clustering of player behavior in computer games in the wild, Proc.
CIG-12, Granada, 2012, pp. 163–170.
[4] A. Drachen, C. Thurau, J. Togelius, G.N. Yannakakis, C. Bauckhage,
Game Data Mining, in M. Seif El-Nasr, A. Drachen, A. Canossa (eds.):
Game Analytics - Maximizing the Value of Player Data, Springer, 2013,
pp. 205–253.
[5] L. Kaufman, P.J. Rousseeuw, Finding Groups in Data: An Introduction
to Cluster Analysis, Chapter 2, John Wiley & Sons, 1990, pp. 68–125.
[6] S. Paskaradevan, J. Denzinger, D. Wehr, Learning cooperative behavior
for the shout-ahead architecture, WIAS Vol. 12(3), IOS Press, 2014,
pp. 309–324.
[7] P.J. Rousseeuw, Silhouettes: a graphical aid to the interpretation and
validation of cluster analysis, J. of Comp. and App. Math. Vol. 20,
1987, pp. 53–65.
[8] J.P. Steghöfer, J. Denzinger, H. Kasinger, B. Bauer, Improving the
Efficiency of Self-Organizing Emergent Systems by an Advisor, Proc.
EASe 2010, Oxford, 2010, pp. 63–72.
[9] D. White, Battle for Wesnoth, http://www.wesnoth.org/ (as seen on
23.2.2015).
[10] C.-W. Wu, Y.-F. Lin, P.S. Yu, V.S. Tseng, Mining high utility episodes
in complex event sequences, Proc. 19th ACM SIGKDD, Chicago, 2013, Fig. 5. Hunting lone enemies: going for the kill
pp. 536–544.

398