Bayesian Programming and Learning for Multi-Player Video Games ...

7.6.3 Possible uses
We recall that we used this model for opening prediction, as a proxy for timing attacks and
aggressiveness. It can also be used:
• for build tree suggestion when wanting to achieve a particular opening. Particularly one
does not have to encode all the openings into a finite state machine: simply train this
model and then ask P(BT |time, opening, λ = 1) to have a distribution on the build trees
that generally are used to achieve this opening.
• as a commentary assistant AI. In the StarCraft and StarCraft 2 communities, there are
a lot of progamers tournaments that are commented and we could provide a tool for
commentators to estimate the probabilities of different openings or technology paths. As
in commented poker matches, where the probabilities of different hands are drawn on
screen for the spectators, we could display the probabilities of openings. In such a setup
we could use more features as the observers and commentators can see everything that
happens (upgrades, units) and we limited ourselves to “key” buildings in the work presented
here.
Possible improvements
First, our prediction model can be upgraded to explicitly store transitions between t and t+1 (or
t − 1 and t) for openings (Op) and for build trees* (BT ). The problem is that P(BT t+1 |BT t )
will be very sparse, so to efficiently learn something (instead of a sparse probability table)
we have to consider a smoothing over the values of BT , perhaps with the distances mentioned
in section 7.5.2. If we can learn P(BT t+1 |BT t ), it would perhaps increase the results of
P(Opening|Observations), and it almost surely would increase P(BuildT ree t+1 |Observations),
which is important for late game predictions.
Incorporating P(Op t−1 ) priors per match-up (from Table 7.1) would lead to better results,
but it would seem like overfitting to us: particularly because we train our robot on games played
by humans whereas we have to play against robots in competitions.
Clearly, some match-ups are handled better, either in the replays labeling part and/or in
the prediction part. Replays could be labeled by humans and we would do supervised learning
then. Or they could be labeled by a combination of rules (as in [Weber and Mateas, 2009])
and statistical analysis (as the method presented here). Finally, the replays could be labeled
by match-up dependent openings (as there are different openings usages by match-ups*, see
Table 7.1), instead of race dependent openings currently. The labels could show either the two
parts of the opening (early and late developments) or the game time at which the label is the
most relevant, as openings are often bimodal (“fast expand into mutas”, “corsairs into reaver”,
etc.).
Finally, a hard problem is detecting the “fake” builds of very highly skilled players. Indeed,
some progamers have build orders which purpose are to fool the opponent into thinking that they
are performing opening A while they are doing B. For instance they could “take early gas” leading
the opponent to think they are going to do tech units, not gather gas and perform an early rush
instead. We think that this can be handled by our model by changing P(Opening|LastOpening)
145