A CBR Module for a Strategy Videogame

Transcription

1 A CBR Module for a Strategy Videogame Rubén Sánchez-Pelegrín 1, Marco Antonio Gómez-Martín 2, Belén Díaz-Agudo 2 1 CES Felipe II, Aranjuez, Madrid 2 Dep. Sistemas Informáticos y Programación Universidad Complutense de Madrid, Spain rsanchez@cesfelipesegundo.com, {marcoa,belend}@sip.ucm.es Abstract. C-evo is a non-commercial free open-source game based on Civilization, one of the most popular turn-based strategy games. One of the most important goals in the development of C-evo is to support the creation of Artificial Intelligence (AI) modules. We have developed one of such AI modules based on Case Based Reasoning (CBR). The project is in an early stage. In this paper we describe the main ideas behind our approach and certain open tasks and extensions that we want to tackle in a near future. One of this extensions we have considered is the use of TIELT to compare different AI modules. 1 Introduction In the last few years AI researchers have found games as an interesting testbed of techniques. In spite of the importance of CBR on the evolution of AI, the CBR community has not made so much effort to use it in games, specially for its addition in commercial games. Our work presented in this paper consists on the design and implementation of an AI module that uses CBR. We have designed this module in the context of a game engine called C-evo but the ideas underlying our approach can be applied to other games. We are specially concerned about strategy games where several decisions are taken using a big amount of variables that describe a certain situation, and where situations tend to recur. C-evo is an open-source game project based on the famous Sid Meier s Civilization II by Microprose and has many basic ideas in common with it. C-evo is a turn-based empire building game about the origination of the human civilization, from the antiquity until the future 3. One of the most important goals in the development of C-evo is to support the creation of AI modules. There are other projects similar to C-evo. Probably the most popular is FreeCiv 4 [5, 12], also an open-source game based on Civilization. We chose C-evo because it is more oriented to AI development. There are many different AI modules developed for C-evo, and this makes it a good testbed for evaluating the performance of our module. Supported by the Spanish Committee of Science & Technology (TIC )

2 Fig. 1. C-evo screenshot However, comparison between different AI modules had to be done by hand in C-evo. To avoid this we have analysed TIELT[1], a Testbed for Investigating and Evaluating Learning Techniques that we will use to compare different CBR solutions in the near future. This paper runs as follows: Section 2 describes our AI module using CBR to select a military unit behaviour, its current state and our current lines of work. Section 3 describes our analysis of TIELT and how it can be used to optimize the comparisons of several modules. Finally, Section 4 concludes this paper. 2 AI project for C-evo C-evo provides an interface with the game engine that enables developers to create an AI module for managing a civilization. The game has a special architecture, based on exchangeable competitor modules, that allows the exchange of the AI for every single player. Thus anyone can develop his own AI algorithm in a DLL apart from the game in the language of his choice, and watch it play against humans, against the standard AI or other AI modules 5. AI modules can gather exactly the same information that a human player can and make exactly the same actions. Indeed, the player interface is another module that uses the same interface to communicate with the game core. This way AI modules cannot cheat, a very typical way of simulating intelligence in video games. Our goal was to develop an AI module, using advanced AI techniques. In particular we used Case-Based Reasoning (CBR) [7, 6] for solving some of the decision problems presented in the management of an empire. There are lowlevel problems (tactical decisions) and high-level (global strategy of the empire). 5 The documentation to create an artificial intelligence module for C-evo is available at

3 Examples of low-level problems are: to choose the next advance to develop, to select government type and to set tax rates, diplomacy, city production or behaviour of a unit. In this first stage we have focused on a single problem: the selection of a military unit behaviour, a tactical problem concerning action selection. 2.1 A concrete problem: military unit behaviour We have focused on a low-level problem: the control of military units. We have chosen this as the first problem to work on because we think it has a big impact on the result of the game. At this time all the other decisions are taken by hand written code. We have not put much effort on developing it, so we cannot expect our AI module to be really competitive with others. Our AI module uses CBR to assign missions to control units. A new mission is assigned to a unit in its creation and every time it completes the prior assigned mission. We have created three missions for military units: Exploring unknown tiles around a given one. The unit goes to the selected tile and moves to the adjacent tile which has more unknown tiles around it. If none of its adjacent tiles has unknown adjacent tiles, the mission concludes. Defending a given city. The unit goes to the city tile and stays there to defend the position. Attacking a given city. The unit goes to the city tile and attacks any enemy defending it. Our cases are stored in an XML file, and each one is composed of: A description of the unit features, and the state of the game relevant to the problem. This description gathers information about the military unit and about its environment. There are features that store the values for attack, defence, movement and experience of the unit. From the environment, we are interested on information about own cities, enemy cities and unknown tiles. For every city (own or enemy) there are features that stores its distance to the unit, and defence of the unit that defends the city tile. For our own cities, there is also a feature for the number of units in the city tile. 6 For every known tile surrounded by any unknown tile there are a feature that stores its distance to the unit. The solution of the problem, that is the mission assigned to the unit: attack one of the enemy cities, defend one of the own cities or explore from one of the known tiles surrounded by unknown tiles. The result of the case, a description of the outcome of the mission, composed by figures extracted from the game engine. It provides features that stores the duration in turns of the mission, number of attacks won, number of 6 The AI interface doesn t provide this figure for enemy cities.

4 defences won, number of enemy cities conquered, number of own cities lost during the mission, number of explored tiles, and whether the unit died or not during the mission. When a new problem comes up, we select the solution we are going to take basing on the cases stored in the case base. We begin with a new query that describes the problem we are dealing with. Description features are obtained from the game engine. We propose a retrieval method that filters an initial case base in several steps. 1. Filter the whole case base using a similarity function to compare the query with the description of the stored cases. We retrieve from the case base the 50 most similar cases to the query problem. 2. Aggregate the 50 retrieved cases into the missions they have assigned, i.e., the solution of the cases. 3. Compute the expected profit of each mission. It is based on the sum of the expected profit of each one of the cases of this mission. The profit of a case is computed using the result component. 4. Select the mission with the highest expected profit. Next, we describe how we solve each one of these steps: A similarity function gets two case descriptions and returns a measure of how similar they are. The similarity is a combination of local similarities of individual features and combinations of two or more of them. For example, we not only compare attack with attack and defence with defence, but also the proportion between attack and defence. This is because units with similar attack-defence ratios usually are used in a similar way, even if the total amount of attack and defence is very different. Similarity between individual features is the proportion between them: sim(x, y) = min(x, y) max(x, y) For determining the similarity between two problem descriptions, we calculate two partial similarities, the similarity between unit features S u and the similarity between world situations S s. Similarity between unit features is obtained using weighted average of its local features. We consider the attack, defence and experience feature less relevant than the others: S u = Sa + S d + S e + 2S m + 2S ar + 2S dr 9 Where: S a similarity between the attack feature. S d similarity between the defence feature. S e similarity between the experience feature. S m similarity between the movement feature. S ar, S dr the similarity of ratios between attack and defence.

5 Similarity between world situations is calculated using arithmetic average of several features and combinations of features: S s = S dnu + S dne + S dno + S dwe + S dwo + S an + S aw + S dn + S dw + S nn + S nw 11 Where: S dnu, S dne, S dno similarity between the nearest distance to an unknown tile, enemy city and own city, respectively. S dwe, S dwo similarity between the distance to the weakest enemy and own city respectively. S an, S aw similarity between the ratios of unit s attack and defence of the nearest enemy city and unit s attack and defence of the weakest enemy city respectively. S dn, S dw similarity between the ratios of unit s defence and defence of the nearest own city and unit s defence and defence of the weakest own city respectively. S nn, S nw similarity between the number of units on the nearest own city and on the weakest own city respectively. Finally, the global similarity S is the product of partial similarities: S = S us s In order to calculate the profit (P ) obtained in each of the retrieved cases, we use a function that aggregates the case result features, returning a single value that is the measure of the success obtained in the mission. The case result features are number of explored tiles (t), number of attacks won (a), number of defences won (d), number of conquered enemy cities (c w ), number of own cities lost during the mission (c l ), number of turns that the mission took (t) and a boolean feature (e) that says if the unit died (e = 1) or not (e = 0) during the mission. P = (t + 5a + 10d + 50c w 100c l ) e We select the set of possible missions we can assign to the unit. We are going to consider only up to five possible missions: exploring the nearest known tile with an adjacent unknown tile, defending the nearest own city, defending the weakest own city, attacking the nearest enemy city or attacking the weakest enemy city. For each one of these missions we select among the retrieved cases those which have that mission as its solution. With these cases, we calculate an expected profit E for the mission. It is an average of the profits of those cases, weighted by the similarity of each case with the problem case. Si P i E = Si We also calculate an uncertainty measure U for each of the possible missions. It depends on the number of cases used for calculating the expected profit, the variance of their profit, and their similarity with the problem case. This

6 way, if we have got similar expected profit from many cases, probably the real profit of the mission will be very close to the expected profit. In this case we have a low amount of uncertainty. On the other hand, if we have calculated the expected profit from few cases, or from cases with very different profits, the uncertainty will be high. Si (P i E) 2 U = Si We randomly modify the expected profit of each of the possible missions. The randomness of the modification depends on the uncertainty; the higher it is, the bigger the randomness is. This way we avoid the algorithm to be too conservative. If we did not use this random factor, the algorithm would discard some solutions basing on a single case which gave a bad result. Given the complex nature of the game, this bad result could be a bit of bad luck, and it is good to give a second opportunity to solutions, although once they worked badly. E = E + rand(0, U) We select the mission with the highest expected profit. We assign it to the unit, and store it as the solution of the problem case. The problem case is not stored yet in the case base. The mission is tracked for obtaining the result of the case until it is completed. When the mission is completed, the query problem becomes a full case, with its result obtained from the game engine. Then this new case is stored in the case base. Our approach to retrieve cases is quite general and applicable to other domains, specially when there are lots of cases described by a big number of features. However, the success of the algorithm strongly depends on the representation of the description, solution and result of the cases, and on the functions used for calculating similarity, profit, expected profit, uncertainty and the randomness modifying the expected profit. All these functions have been hand-coded and are specific for this game. They were written based on our knowledge of the game. In section 2.3 we discuss how learning could be used for improving them. 2.2 Evaluation C-evo allows to play an AI tournament consistent on several games between several AI modules. We tried to confront our module with a version of itself without learning (an AI dummy module); all we did was disabling the case storing, so the module had always an empty case base. The result was a set of ties. Although the learning could improve slightly the performance of the AI module, it was not enough to beat the opponent. We state that this is because the problem solved is only a small part of all the decisions that an AI module must take. The rest of the module was hand coded in a very simple way, so it doesn t play well enough to get a win. Also, the performance of the algorithm can be improved in several ways, some of them are discussed in the next section.

7 The efficiency was good while the size of the case base was not so big to fill RAM memory. When the case base size grows much the efficiency falls. In the next subsection we also discuss some solutions to this problem. 2.3 Extensions to the basic approach In the previously described algorithm, some hand tuned functions were used for calculating things as similarity between cases or profit of a result. This way, the success of the algorithm heavily depends on the accuracy of the human expert modifying these functions. It would be better to use some machine learning technique for that task. To learn the profit of a mission, we can associate each mission result with the final result (win, lost or draw) that the AI module got in the game where the mission took place. This information enables machine learning to associate which mission results tend to lead to each final result. For those results which occurs in a victory, the profit function would tend to give higher values. This way we would have a two level reasoning between raw data extracted from the game engine and decisions taken. For this purpose, Genetic Algorithms, Neuronal Nets, Bayesian Nets or CBR could be used to learn the profit function. Similarity measures could be learned considering that truly similar cases with similar solutions would tend to lead to similar results. Based on this hypothesis we could learn a similarity function that give high values of similarity for cases with similar results under the same mission, finding which features of cases are more relevant on this similarity and to what extent. For this purpose we are studying previous work in this area [11] and we are considering the use of some classical learning algorithms like genetic algorithms. A very serious trouble of the algorithm is the growth of the case base, that hurts the efficiency. Usually, case-based systems solve this problem storing only new cases different enough from existent cases. However, case-based systems usually only need to recover the most similar case with the problem, and they reason only from one case. This is possible because identical problems should have identical outputs. In our problem this is false; identical decisions taken on identical situations could lead to different results, due to the freedom of choice of the opponent and the incompleteness of the information. Randomness would take part too in most games, although in this one it doesn t exist. We need to store somehow the information of all cases produced, or we will lose valuable information. A system of indexing the cases would lighten this problem very much. This way it would not be necessary to calculate the similarity measure for all cases in the database, but only those that are solid candidates to be similar enough to the problem. However, it would not be a complete solution, because the case base size would keep growing indefinitely. It only defers the problem. The solution to the growth of case base would be clustering cases. If we have identical cases, then we have no need of storing them separately; we can store one case, and have a counter for the number of times it has happened. When reasoning, this case would be weighted by this counter for calculating expected profit

8 and uncertainty. However, case descriptions are complex enough for allowing a very high number of different possible cases. So it would be needed to group very similar cases together in a cluster. A general case would represent the cluster, using a counter for the number of cases implied. The description of the case that represented a cluster would have an average measure of the features that distinguish them, instead of the exact values of each one. Some information would be lost on this process, but it is necessary to maintain the computational feasibility of this method. Ideas for this task could also be extracted from previous work [2]. The use of CBR could be extended to another low level problems of the game. Each problem would have one case base, with a case representation suitable to that problem. However, some problems could share the same case base; for example, the problem of selecting the military unit to be built in a city could use the case base used for the problem of the military unit behaviour. Units produced should be those that produce better results for the current situation of the game. The reasoning would be completely different, but the data would be the same. High level problems could lead to more challenging strategic decisions, where we think CBR could be a very useful technique, given that it usually works well in situations where the environment is complex, and the rules of its behaviour are unknown or fuzzy. Examples of such problems are coordinating units action, or selection of the global strategy for the game. 3 Module comparison with TIELT As described in Section 2.2, we had to test our CBR module against the AI dummy module to check its abilities. This comparison was made by hand, launching the game and selecting the AI modules (DLLs) we wanted to test. This process was also needed when comparing CBR modules with different weights in the similarity function. As described in Section 2.3, there are several extensions that can be done in our module. We envision that we will require a great amount of tests to compare their abilities, so they should be accomplished in a more suitable way. In that sense we have been exploring the possibility of use TIELT (Testbed for Investigating and Evaluating Learning Techniques), a middleware testbed that facilitates and encourages the evaluation of learning systems in the context of interactive computer games [1]. Our first analysis has revealed that we could benefit from TIELT in: We could compare the functionality of our own AI modules without requiring such amount of manual work. We could make use of our AI modules in other game engines. In Section 1 we mentioned FreeCiv as another open-source game with a set of rules very similar to C-evo. If we manage to unify the rules of both games, we will be able to test our AI modules independently of which game engine is being

9 used. Moreover, we could test our AI modules against the default intelligence of different games. As TIELT acts as a middleware, the programming language used for the implementation of the module is not restricted to those imposed by the game engine. Though in the specific context of C-evo the restriction is just the construction of a DLL with a concrete interface, using TIELT we could implement our module in a independent process and use Java as unique language, without the need of implement a DLL that launchs a Java Virtual Machine. According to TIELT documentation our next step is to create a model containing the game rules. As a starting point, we have analysed the study made by Mad Doc Software in [8] and we envision a similar model to the games we are focusing on. The Game Model has to be complete enough to provide all the available information to the different AI modules. We also have to define the Game Model Interface that contains all the information related to the communication between a specific game engine and the middleware. As C-evo (the game engine) allows extensions of AI just by means of DLL programming, we will need to create a simple DLL that acts as communication layer between the game engine and TIELT. From the C-evo point of view, this layer will be an AI module, while from the TIELT point of view, it will be the game engine. This DLL is the only part dependent of C-evo. In the future, if we want to use our AI modules in FreeCiv, we just will have to create the specific communication layer that respects the rules impose by the game API. The last step is the implementation of the proper AI module. Nowadays it consists of a DLL in Visual C++, but we will implement it as an autonomous system process that will communicate with TIELT using sockets. This allows us to implement our new modules using frameworks of machine learning or CBR. In particular, we want to use jcolibri 7 to implement the proposed extensions in Java. 4 Conclusions Our ongoing work studies the applicability and advantages of the CBR basics within the videogames field. In this paper we have described an AI module based on CBR that has been applied to C-Evo, a turn based strategy game. This project is in an early stage and in this paper we have mainly described the main ideas behind our approach and certain open tasks and extensions that we want to tackle in a near future. The construction of the underlying CBR routines has obviously involved a great deal of hand-crafting. To overcome this critical issue our approach proposes to learn the corresponding similarity measures. To the authors knowledge CBR has not typically been used as the main underlying AI technique in commercial video games. There are some research 7

10 papers like [4, 3], but the industry seems not to use CBR in commercial games, although there are several descriptions of similar techniques that take advantage of previous experiences without explicitly naming it CBR [9]. Even so, we consider it a promising technique for AI in computer games. CBR is probably among the AI techniques the closest one to human thinking. AI for computer games should not only be intelligent, but also believable [10]. We think this makes CBR specially suitable to AI for computer games. Though we already have some preliminary experimental results this project is in an early stage. As shown in Section 2.3, there are still several improvements to be developed. References 1. D. W. Aha and M. Molineaux. Integrating learning in interactive gaming simulators. In Challenges in Game AI: Papers of the AAAI O4 Workshop. San Jose, CA: (Technical Report WS-04-04) AAAI Press, R. Bergmann and W. Wilke. On the role of abstraction in case-based reasoning. In EWCBR, pages 28 43, M. Fagan and P. Cunningham. Case-based plan recognition in computer games. In ICCBR, pages , T. Gabel and M. M. Veloso. Selecting heterogeneous team players by case-based reasoning: A case study in robotic soccer simulation. Technical report CMU-CS , Computer Science Department, Carnegie Mellon University, P. A. Houk. A strategic game playing agent for FreeCiv. Technical report NWU-CS , Evanston, IL: Northwestern University, Department of Computer Science, J. Kolodner. Case-based reasoning. Morgan Kaufmann, Calif., US., D. Leake. Case-Based Reasoning: Experiences, Lessons, & Future Directions. AAAI Press / The MIT Press. ISBN X, Mad Doc Software. TIELT challenge problem, Available at TIELT Challenge Problem.pdf. 9. F. Mommersteeg. AI Game Programming Wisdom, chapter Pattern Recognition with Sequential Prediction. Charles River Media, Inc., Rockland, MA, USA, A. Nareyek. AI in computer games. ACM Queue, 1(10):58 65, A. Stahl. Learning of knowledge intensive similarity measures in case based reasoning. Phd thesis, University of Kaiserlauten, P. Ulam, A. Goel, and J. Jones. Reflection in action: Model-based self-adaptation in game playing agents. In D. Fu and J. Orkin, editors, Challenges in Game Artificial Intelligence: Papers from the AAAI Workshop. San Jose, CA: AAAI Press, 2004.