Implementing a Wall-In Building Placement inStarCraft with Declarative Programming

Michal Certicky

Agent Technology Center, Czech Technical University in Praguemichal.certicky@agents.fel.cvut.cz

June 2013

In real-time strategy games like StarCraft, skilled players often block the en-

trance to their base with buildings to prevent the opponent’s units from getting

inside. This technique, called “walling-in”, is a vital part of player’s skill set,

allowing him to survive early aggression. However, current artificial players

(bots) do not possess this skill, due to numerous inconveniences surfacing du-

ring its implementation in imperative languages like C++ or Java. In this text,

written as a guide for bot programmers, we address the problem of finding

an appropriate building placement that would block the entrance to player’s

base, and present a ready to use declarative solution employing the paradigm

of answer set programming (ASP). We also encourage the readers to experi-

ment with different declarative approaches to this problem.

Keywords: StarCraft, Real-time Strategy, Answer Set Programming, Wall-In, BWAPI

1

arX

iv:1

306.

4460

v1 [

cs.A

I] 1

9 Ju

n 20

13

1 Introduction

StarCraft1 is a popular computer game representing a Real-time Strategy (RTS) genre. In a

typical RTS setting, players (either human or artificial) are in control of various structures (buil-

dings) and units which they order to gather resources, build additional units and structures, or

attack the opponent. RTS games are in general a very interesting domain for Artificial Intelli-

gence (AI) research, since they represent well-defined complex adversarial systems and can be

divided into many interesting sub-problems [2].

Expert knowledge about such a complex environment is extensive and hard-coding the reaso-

ning over it in an imperative programming language like C++ or Java may in some cases prove

time-consuming and inconvenient. Various declarative knowledge representation paradigms

are well-suited for some of the subproblems of RTS AI, and their corresponding state-of-the-art

solvers can often do most of the work for us.

In this text, we address the subproblem of finding an appropriate building placement that would

effectively block the entrance to player’s base region. Skilled human players often block the

narrow entrance (chokepoint) to their base with their own structures in order to prevent the

enemy units from getting inside. This technique is a vital component of any StarCraft player’s

skill set, allowing him to survive the early phase of the game against aggressive opponents.

Over past few years, we have seen a great amount of research conducted in the area of artifi-

cial intelligence for RTS games, especially StarCraft, thanks to the introduction of the BWAPI

framework [3]. Many of relevant publications deal with various machine learning approaches,

either for micro-management in combat [15, 13] or for macro-economic or strategic tasks

[7, 14, 4]. Others solve the opponent modelling [8] or optimization problems over possible

build orders [5]. However, there has been no publications dealing with the problem of wall-in

1StarCraft and StarCraft: Brood War are trademarks of Blizzard Entertain ment, Inc. in the U.S. and/or otherCountries.

2

building placement so far. Even though there is a large number of high-quality artificial players

(bots) competing in long-term tournaments like SSCAI2, or shorter events on conferences like

AIIDE or CIG, they seem to perform poorly against early aggression, since none of them is able

to use buildings to block the entrance to their base. We write this text in hope that it will serve

as a guide for bot creators, allowing them to solve this problem quickly and effortlessly.

After describing the problem at hand more closely in section 2, we will briefly outline the

semantics of answer set programming (ASP), a paradigm of logic programming employed in

our prototypical problem encoding described in detail in section 4.

2 The Problem Description

The problem of wall-in building placement can be seen as a constraint satisfaction problem

(CSP) [6]. Typically, a CSP is defined as a triple 〈X,D,C〉, where X is a set of variables, D a

set of values to be assigned to them and C is a set of constraints that need to be satisfied in any

valid solution (assignment). In our case, variables correspond to individual buildings that we

want to use in our blockade (wall) and values are all the tile positions3 around the chokepoint.

In other words, we need to assign a placement to every building we are going to build, such that

all of the following constraints are satisfied:

• Every building can be built on its assigned location (this depends on the terrain).

• Buildings do not overlap.

• There will not be any walkable path leading from “outside” region to our base, after the

buildings are constructed.

2http://sscaitournament.com/3The notion of a “tile position” will be explained further in the text.

3

Note (Protoss): The situation is slightly more complicated when our bot plays as Protoss (one

of three playable races in StarCraft). We need one more constraint about all the buildings being

powered by a Pylon, and we do not want to wall-in completely, because otherwise we would

not be able to get out of the base (in contrast, the Terran bots can lift their buildings to get out

and Zerg bots generally do not build walls at all). Therefore, in addition to buildings, we need

to include one unit in our wall (typically a Zealot). Fortunately, this is simply solved by adding

one extra variable to X (see figure 1).

Figure 1: Example of wall-in placement as a Protoss. The wall consists of a Gate-way, Forge and Pylon structures and a Zealot unit. In CSP terms, variables from X ={Gateway, Pylon, Forge, Zealot} are assigned the values of (118, 23), (122, 22), (124, 23)and (126, 23) respectively.

4

Note (Tiles): For the purposes of building placement, the map in StarCraft is divided into a grid

of square 32×32px “build tiles”. The buildings can only be placed onto discrete positions within

this grid (unlike units, which can move around freely). Every building then occupies several

tile positions, depending on its size, while its position is usually denoted by the coordinates of

the top left tile occupied by it.

The game engine of StarCraft causes one more complication: the buildings do not block the

entire area covered by the tiles they occupy. For example (see figure 1), a Forge building

occupies an area of 3 × 2 tiles. However, there is a 12px wide walkable gap at the left side,

and an 11px wide gap at the right side of the Forge. The sizes of these gaps are hard-coded in

the game engine and are different for every building type. See the gap sizes for all the Terran

and Protoss building types in figure 2. Some walls might contain gaps between the buildings

that are wide enough for smaller units (e.g. Zerglings with their 16× 16px dimension) to walk

through. For example, there is a 27px wide gap between the Forge and the Pylon in figure 1. If

gaps like this cannot be avoided, they need to be blocked afterwards by additional units.

This brings us to the optimization part of our problem. A CSP defined like this often has more

than one valid solution. Constraints may be satisfied by various assignments of tile positions to

buildings. We can, however, define and select the best possible valid assignment based on how

wide the gaps between individual buildings are.

Both the constraint satisfaction and optimization problems can be solved simultaneously by a

certain paradigm of logic programming, called the Answer Set Programming or ASP (details in

the following section). This, together with the existence of effective solvers, is the reason why

we have chosen the ASP for our implementation. However, we emphasize that various other

declarative approaches (different paradigms of logic programming, constraint programming,

etc.) can undoubtedly be used as well. The ideas and solutions described here should be easily

transferable to other languages and tools.

5

Figure 2: Complete enumeration of gap sizes around Terran and Protoss buildings. Negativegap sizes mean that a given building blocks an area outside its assigned tiles.

To implement a wall-in placement generator in an imperative programming language, one

would need to solve the following subproblems one by one:

• Search over the space of all possible building placements.

• Implement a proper pathfinding algorithm, which is not so easy with different gaps be-

tween buildings.

• Call this algorithm for every valid placement to determine if the wall is indeed tight.

In contrast to that, when taking a declarative approach, we only need to define the problem

correctly. The search over a solution space, constraint testing and optimization is taken care of

by the solver (in our case, an ASP solver clingo [9]).

6

3 Answer Set Programming

Answer Set Programming [11, 12, 1] has lately become a popular declarative problem solving

paradigm with growing number of applications.

The original language associated with ASP allows us to formalize various kinds of common

sense knowledge and reasoning, including constraint satisfaction and optimization. The lan-

guage is a product of a research aimed at defining a formal semantics for logic programs with

default negation [11], and was extended to allow also a classical (or explicit) negation in 1991

[12]. An ASP logic program is a set of rules of the following form:

h← l1, . . . , lm, not lm+1, . . . not ln.

where h and l1, . . . , ln are classical first-order-logic literals and not denotes a default nega-

tion. Informally, such rule means that “if you believe l1, . . . , lm, and have no reason to be-

lieve any of lm+1, . . . , ln, then you must believe h”. The part to the right of the “←” symbol

(l1, . . . , lm, not lm+1, . . . not ln) is called a body, while the part to the left of it (h) is called a

head of the rule. Rules with an empty body are called facts. Rules with empty head are called

constraints.

The ASP semantics is built on the concept of answer sets. Consider a logic program Π and a

consistent set of classical literals S. We can then get a subprogram called program reduct of Π

w.r.t. set S (denoted ΠS) by removing each rule that contains not l, such that l ∈ S, in its body,

and by removing every “not l” statement, such that l /∈ S. We say that a set of classical literals

S is closed under a rule a, if holds body(a) ⊆ S ⇒ head(a) ∈ S.

Definition 1 (Answer Set) Let Π be a logic program. Any minimal set S of literals closed

under all the rules of ΠS is called an answer set of Π.

Intuitively, an answer set represents one possible meaning of knowledge encoded by logic pro-

gram Π and a set of classical literals S. In a typical case like ours, one answer set corresponds

7

to one valid solution of a problem encoded by our logic program. If the ASP solver returns

more than one answer set, there is more than one solution. If it fails to return any answer sets,

no solution to this problem exists.

4 Encoding the Problem in ASP

For our implementation, we were using a modern ASP solver called clingo4. It supports an

extended modelling language, described in [9] and [10]. In addition to basic ASP constructs

(rules, facts, constraints), it has a support for generator rules, optimization statements and

has a set of built-in arithmetic functions and aggregates, making the problem definition more

convenient for us.

Our bot needed to prepare a logic program describing the current problem instance (finding a

wall-in placement with a given set of buildings at a certain chokepoint), pass it to the solver,

read the results from standard output and parse them to obtain resulting tile positions. The

solver accepts this logic program either from standard input, or it can be read from a text file

(command to execute is then: “clingo findWallPlacement.txt” 5). Contents of the

findWallPlacement.txt file will be described in the rest of this section. Typical output

returned by the solver is depicted in figure 3.

Answer: 1place(zealot,126,23) place(pylon,122,22) place(gateway,118,23) place(forge,124,23)Optimization: 42 0OPTIMUM FOUND

Figure 3: Output of the ASP solver corresponding to the wall from figure 1.

One call of the ASP solver with our problem encoding takes less than 200 miliseconds on a

4http://potassco.sourceforge.net/5In our implementation, we call the “clingo --asp09 findWallPlacement.txt” command. The

--asp09 flag instructs clingo to display results in the format of ASP Competition’09, which is easier to parse.

8

single-CPU virtual machine running Windows XP with 1GB of available RAM. This allows us

to attempt to compute the wall placement with fewer buildings at first, and then keep adding

more of them, until the wall-in is possible6. In the case from figure 1, we first tried to compute

the wall with only a Gateway, Pylon and a Zealot. Since this was not possible, we tried adding

a Forge to our logic program and called the solver again (this time with success).

4.1 Buildings to Use

The first part of our logic program in findWallPlacement.txt file contains an encoding

of the buildings we want to use. First of all, we use BWAPI to generate the following set of

facts defining the building types, their sizes and gaps around them (notice the fake “zealots”

building type).

% Specify building types, their sizes and gaps.buildingType(forgeType).buildingType(gatewayType).buildingType(pylonType).buildingType(zealotsType).

width(gatewayType,4). height(gatewayType,3).width(forgeType,3). height(forgeType,2).width(pylonType,2). height(pylonType,2).width(zealotsType,1). height(zealotsType,1).

leftGap(gatewayType,16). rightGap(gatewayType,15). topGap(gatewayType,16). bottomGap(gatewayType,7).leftGap(forgeType,12). rightGap(forgeType,11). topGap(forgeType,8). bottomGap(forgeType,11).leftGap(pylonType,16). rightGap(pylonType,15). topGap(pylonType,20). bottomGap(pylonType,11).leftGap(zealotsType,0). rightGap(zealotsType,0). topGap(zealotsType,0). bottomGap(zealotsType,0).

After that, we need to specify the building instances which we want to have in our wall and

assign them to their corresponding types. This can be done with the following collection of

ASP facts:

% Specify what building instances to build.building(pylon1).type(pylon1,pylonType).building(forge1).type(forge1,forgeType).building(gateway1).

6The wall-in is possible, if the solver returns some non-zero number of answer sets. If it fails to return any, itmeans that the given chokepoint cannot be blocked by a given set of buildings.

9

type(gateway1,gatewayType).building(zealots).type(zealots1,zealotsType).

Following constraint simply states that two different buildings must not occupy the same tile

position (must not overlap). Note that the “←” symbol from the rule definition above is written

as “:-” in our text file. Also, the convention in ASP is that constants (forge1, pylonType) start

with lowercase letters or numbers, while the variables are uppercase (B2, X, Y).

% Constraint: Two buildings cannot occupy the same tile.:- occupiedBy(B1,X,Y), occupiedBy(B2,X,Y), B1!=B2.

However, we still need to specify which tile positions are occupied by which buildings. This

is taken care of by the following rule. Here, we use previously established description of the

type, width and height of our buildings. The “place” literal is especially important and will be

explained in subsection 4.4. Intuitively, this rule says that if we place building B on tile (X1, Y1)

and X1 ≤ X2 < X1+ width of B, and at the same time Y1 ≤ Y2 < Y1+ height of B, then also

the (X2, Y2) tile is occupied by B.

% Tiles occupied by the buildings.occupiedBy(B,X2,Y2) :- place(B,X1,Y1),

type(B,BT), width(BT,Z), height(BT,Q),X2 >= X1, X2 < X1+Z, Y2 >= Y1, Y2 < Y1+Q,walkableTile(X2,Y2).

Following four rules simply compute the horizontal and vertical gaps between every pair of

adjacent tiles occupied by different buildings. The verticalGap and horizontalGap literals

will be used during the optimization.

% Gaps between every two adjacent tiles, that are occupied by buildings.verticalGap(X1,Y1,X2,Y2,G) :-

occupiedBy(B1,X1,Y1), occupiedBy(B2,X2,Y2),B1 != B2, X1=X2, Y1=Y2-1, G=S1+S2,type(B1,T1), type(B2,T2), bottomGap(T1,S1), topGap(T2,S2).

verticalGap(X1,Y1,X2,Y2,G) :-occupiedBy(B1,X1,Y1), occupiedBy(B2,X2,Y2),

10

B1 != B2, X1=X2, Y1=Y2+1, G=S1+S2,type(B1,T1), type(B2,T2), bottomGap(T2,S2), topGap(T1,S1).

horizontalGap(X1,Y1,X2,Y2,G) :-occupiedBy(B1,X1,Y1), occupiedBy(B2,X2,Y2),B1 != B2, X1=X2-1, Y1=Y2, G=S1+S2,type(B1,T1), type(B2,T2), rightGap(T1,S1), leftGap(T2,S2).

horizontalGap(X1,Y1,X2,Y2,G) :-occupiedBy(B1,X1,Y1), occupiedBy(B2,X2,Y2),B1 != B2, X1=X2+1, Y1=Y2, G=S1+S2,type(B1,T1), type(B2,T2), rightGap(T2,S2), leftGap(T1,S1).

4.2 Terrain Encoding

Now we need to express what the terrain around the chokepoint looks like. Specifically, we

need to have a set of facts describing which tile positions are walkable and where there is

enough space to build individual building types. Information about this is easily accessible via

BWAPI.

walkableTile(87,11).buildable(pylonType,86,8).buildable(gatewayType,90,8).buildable(pylonType,85,19).buildable(pylonType,88,13).walkableTile(94,21).buildable(zealotsType,93,10).buildable(pylonType,88,19).walkableTile(94,9).buildable(gatewayType,85,11).walkableTile(88,9).buildable(pylonType,89,11).walkableTile(94,18).walkableTile(89,21).

...etc.

To keep the computation times low, we only take into account the tiles from a certain area around

the chokepoint. In our implementation, we considered a 16-tile radius around the chokepoint’s

center.

11

Figure 4: Terrain around the chokepoint. Blue squares denote the tiles where a Forge can bebuilt and red squares the tiles where we can build a Gateway.

In addition to that, we also need to have a specification of two important tile positions - one

inside our base region and the other one outside of it. These will be used when determining if

the wall blocks the passage or not. If there is no walkable path between these two positions, the

wall is tight.

insideBase(94,10).outsideBase(84,22).

For the insideBase position, we simply select the tile from within our considered radius that is

closest to our base. Similarly, the outsideBase is a tile position that is closest to the center of

the outer region.

4.3 Reachability

The following constraint says that units must not be able to reach the base region (specifically

position X2, Y2) from the outside region (position X1, Y1).

% Constraint: Inside of the base must not be reachable.:- insideBase(X2,Y2), outsideBase(X1,Y1), canReach(X2,Y2).

12

However, we still need to declare which tiles are reachable. The following set of rules basically

takes care of the pathfinding problem. First of them says that a walkable position is blocked,

if it is occupied by a building. Second rule states that the outsideBase position is reachable

from itself (obviously). A collection of eight rules after that recursively identifies a position as

reachable if it is not blocked, and it has a reachable neighbor in any of the eight directions.

% Reachability between tiles.blocked(X,Y) :- occupiedBy(B,X,Y), building(B), walkableTile(X,Y).canReach(X,Y) :- outsideBase(X,Y).

canReach(X2,Y) :-canReach(X1,Y), X1=X2+1, walkableTile(X1,Y), walkableTile(X2,Y),not blocked(X1,Y), not blocked(X2,Y).

canReach(X2,Y) :-canReach(X1,Y), X1=X2-1, walkableTile(X1,Y), walkableTile(X2,Y),not blocked(X1,Y), not blocked(X2,Y).

canReach(X,Y2) :-canReach(X,Y1), Y1=Y2+1, walkableTile(X,Y1), walkableTile(X,Y2),not blocked(X,Y1), not blocked(X,Y2).

canReach(X,Y2) :-canReach(X,Y1), Y1=Y2-1, walkableTile(X,Y1), walkableTile(X,Y2),not blocked(X,Y1), not blocked(X,Y2).

canReach(X2,Y2) :-canReach(X1,Y1), X1=X2+1, Y1=Y2+1, walkableTile(X1,Y1), walkableTile(X2,Y2),not blocked(X1,Y1), not blocked(X2,Y2).

canReach(X2,Y2) :-canReach(X1,Y1), X1=X2-1, Y1=Y2+1, walkableTile(X1,Y1), walkableTile(X2,Y2),not blocked(X1,Y1), not blocked(X2,Y2).

canReach(X2,Y2) :-canReach(X1,Y1), X1=X2+1, Y1=Y2-1, walkableTile(X1,Y1), walkableTile(X2,Y2),not blocked(X1,Y1), not blocked(X2,Y2).

canReach(X2,Y2) :-canReach(X1,Y1), X1=X2-1, Y1=Y2-1, walkableTile(X1,Y1), walkableTile(X2,Y2),not blocked(X1,Y1), not blocked(X2,Y2).

There is, however, one more source of reachability in StarCraft - gaps at the sides of the buil-

dings. Because of them, the blocked locations may sometimes be reachable too. To make our

problem representation more precise, we should take them into account as well. In section 4.1,

we computed the horizontal and vertical gaps between the pairs of tile positions, which will be

used now.

First of all, we specify a pixel dimensions of an enemy unit type that we want to lock outside of

our base (in this case, it is the smallest unit in the game: 16× 16px Zergling). Then we use the

13

following eight rules to declare more positions reachable (from corresponding directions) if the

gap is wide enough, even if these positions are blocked.

% Using gaps to reach (walk on) blocked locations.enemyUnitX(16). enemyUnitY(16).canReach(X1,Y1) :- horizontalGap(X1,Y1,X2,Y1,G), G >= S, X2=X1+1, canReach(X1,Y3), Y3=Y1+1, enemyUnitX(S).canReach(X1,Y1) :- horizontalGap(X1,Y1,X2,Y1,G), G >= S, X2=X1-1, canReach(X1,Y3), Y3=Y1+1, enemyUnitX(S).canReach(X1,Y1) :- horizontalGap(X1,Y1,X2,Y1,G), G >= S, X2=X1+1, canReach(X1,Y3), Y3=Y1-1, enemyUnitX(S).canReach(X1,Y1) :- horizontalGap(X1,Y1,X2,Y1,G), G >= S, X2=X1-1, canReach(X1,Y3), Y3=Y1-1, enemyUnitX(S).canReach(X1,Y1) :- verticalGap(X1,Y1,X1,Y2,G), G >= S, Y2=Y1+1, canReach(X3,Y1), X3=X1-1, enemyUnitY(S).canReach(X1,Y1) :- verticalGap(X1,Y1,X1,Y2,G), G >= S, Y2=Y1-1, canReach(X3,Y1), X3=X1-1, enemyUnitY(S).canReach(X1,Y1) :- verticalGap(X1,Y1,X1,Y2,G), G >= S, Y2=Y1+1, canReach(X3,Y1), X3=X1+1, enemyUnitY(S).canReach(X1,Y1) :- verticalGap(X1,Y1,X1,Y2,G), G >= S, Y2=Y1-1, canReach(X3,Y1), X3=X1+1, enemyUnitY(S).

Now we should have our terrain, building instances, reachability, and all the constraints ready,

so we can finally start generating solutions.

4.4 Generate and Test Method

Our logic program uses the “generate-and-test” organization that is very often employed in

ASP-based problem solving. The idea is simple: we use so-called generator rules (or choice

rules if generators are not supported by our solver) to describe a large set of “potential solutions”

to our problem. In our case, any building placement is a potential solution. Each of them is then

tested - we check if all the constraints are satisfied in it. If there are some constraints, that are

not satisfied, the solution is thrown away. Otherwise, it is returned as an answer set.

The generator rules for our wall-in placement problem are depicted below (there is one rule

for every building instance7). For example, the first rule says that “for every X and Y , such

that forgeType is buildable on (X, Y ), we want to generate and check potential solutions with

exactly one literal place(forge1, X, Y )” (exactly one, because we want every building instance

to be placed, and no building can be placed on more than one position at the same time).

7Note that it is also possible to write a single generator rule for all the building instances. We have chosen theencoding with multiple generator rules for this text, because we feel it is more intuitive.

14

% Generate all the potential placements.1[place(forge1,X,Y) : buildable(forgeType,X,Y)]1.1[place(pylon1,X,Y) : buildable(pylonType,X,Y)]1.1[place(gateway1,X,Y) : buildable(gatewayType,X,Y)]1.1[place(zealots,X,Y) : buildable(zealotsType,X,Y)]1.

On the output, the ASP solver returns the answer sets corresponding to solutions with exactly

one place literal for every building instance, where all the constraints are satisfied.

4.5 Optimization

As we mentioned before, there might be more valid solutions to our problem, some of which

are better than others. We consider the wall-in better, if there are less wide gaps in it. The ASP

solver can be instructed to find the best among all the valid solutions by including the following

two optimization statements in our logic program.

% Optimization statements.#minimize [verticalGap(X1,Y1,X2,Y2,G) = G ].#minimize [horizontalGap(X1,Y1,X2,Y2,G) = G ].

Note that we can omit the optimization statements if we do not necessarily need the best possible

solution. By doing this, we can save some computation time, since computing any answer set

is faster than computing the best one.

Logic programs, like the one described in this section, can be easily generated by any bot

programmed in BWAPI and used to find a wall-in placement for most of the chokepoints in

typical StarCraft tournament maps. The computation time is bearable, considering that the bots

do not need to solve this problem very frequently (usually only once per game).

5 Summary

We have shown how a declarative programming approach can be used to generate wall-in place-

ments in StarCraft (and possibly other RTS games) quite effortlessly.

15

This text, written as a guide for bot programmers, addresses all the relevant subproblems, like

terrain and building encoding, pathfinding/reachability and optimization, and presents a dec-

larative solution to each of them. The ASP encoding, presented here and employed in our

implementation, can be directly adopted by other bot programmers. However, we encourage

readers to experiment with different declarative paradigms and technologies.

References

[1] C. Baral. Knowledge Representation, Reasoning and Declarative Problem Solving. Cam-

bridge University Press. 2003.

[2] Buro, Michael. Call for AI research in RTS games. Proceedings of the AAAI-04 Workshop

on Challenges in Game AI. 2004.

[3] BWAPI, 2013. http://code.google.com/p/bwapi/, accessed 2013-06-06.

[4] Certicky, Martin, and Certicky Michal. Case-Based Reasoning for Army Compositions in

Real-Time Strategy Games. Proceedings of SCYR 2013, Student Conference of Young Re-

searchers. 2013.

[5] Churchill, David, and Michael Buro. Build order optimization in starcraft. Proceedings of

AIIDE (2011): 14-19.

[6] Dechter, Rina, and Avi Dechter. Belief maintenance in dynamic constraint networks. Uni-

versity of California, Computer Science Department, 1988.

[7] Dereszynski, Ethan, et al. Learning probabilistic behavior models in real-time strategy

games. Seventh Artificial Intelligence and Interactive Digital Entertainment Conference.

2011.

16

[8] Fjell, Magnus Sellereite, and Stian Veum Mllersen. Opponent Modeling and Strategic Rea-

soning in the Real-time Strategy Game Starcraft. Diss. Norwegian University of Science

and Technology, 2012.

[9] Gebser, Martin, et al. A users guide to gringo, clasp, clingo, and iclingo. (2008).

[10] Gebser, Martin, et al. On the input language of ASP grounder gringo. Logic Programming

and Nonmonotonic Reasoning. Springer Berlin Heidelberg, 2009. 502-508.

[11] M. Gelfond, V. Lifschitz. The stable model semantics for logic programming. In Proceed-

ings of ICLP-88: 1070-1080. 1988.

[12] M. Gelfond, V. Lifschitz. Classical negation in logic programs and disjunctive databases.

New Generation Computing: 365-385. 1991.

[13] Rathe, Espen Auran, and Jrgen Be Svendsen. Micromanagement in StarCraft using Poten-

tial Fields tuned with a Multi-Objective Genetic Algorithm. Diss. Norwegian University of

Science and Technology, 2012.

[14] Synnaeve, Gabriel, and Pierre Bessiere. A Dataset for StarCraft AI and an Example of

Armies Clustering. Artificial Intelligence in Adversarial Real-Time Games: Papers from

the 2012 AIIDE Workshop AAAI Technical Report WS-12-15. 2012.

[15] Wender, Stefan, and Ian Watson. Applying reinforcement learning to small scale combat

in the real-time strategy game StarCraft: Broodwar. Computational Intelligence and Games

(CIG), 2012 IEEE Conference on. IEEE, 2012.

17