Adjusting game difficulty level through Formal ... - Semantic Scholar

Adjusting game difficulty level through Formal Concept Analysis ∗ Marco A. G´omez-Mart´ın, Pedro P. G´omez-Mart´ın Pedro A. Gonz´alez-Calero and Bel´en D´ıaz-Agudo, Dep. Sistemas Inform´aticos y Programaci´on Universidad Complutense de Madrid Madrid, Spain email: {marcoa,pedrop,pedro,belend}@sip.ucm.es

Abstract In order to reach as many players as possible, videogames usually allow the user to choose the difficulty level. To do it, game designers have to decide the values that some game parameters will have depending on that decision. In simple videogames this is almost trivial: minesweeper is harder with longer board sizes and number of mines. In more complex games, game designers may take advantage of data mining to establish which of all the possible parameters will affect positively to the player experience. This paper describes the use of Formal Concept Analysis to help to balance the game using the logs obtained in the tests made prior the release of the game.

1

Introduction

Nowadays, the number of available videogames is impressive. If game developers want to increase the number of sold copies, they must make them suitable for a big amount of players, with different game skills, interests, and time available. In fact, loads of people miss some kind of help when playing games. All players have inevitably got stuck some time, and have finally given the game(s) up. The evidence is the great amount of game magazines and Internet sites that offer the visitors guides, cheats, hints and walkthroughs of games. There are players that argue that these difficulties are the essence of games, but most of them belongs to the so-called “hard-core” gamers groups, people who play many hours per week and have a great intuition about games. The effort required to finish a game affects the player amusement, so designers must balance the games trying to make them not too easy nor too hard. ∗ Supported

by the Spanish Committee of Education & Science (TIN2005-09382-C02-01)

1

But, on the other hand, the time needed to overcome a level or defeat an enemy greatly differs depending on the player ability. Due to both facts, it is common practise to add different difficulty levels to games. Obviously, this is an advantage for users. But, being quite difficult to balance a game, this multiplies the design work. Clearly, in simple games, the decision to adjust the difficulty level is light. For example, in the well-known game of Pac-Man, an evident way to simplify each session consists on decreasing the number of ghosts and their speed, or increasing the number of ghostbuster pills. But when the game complexity increases, the number of adaptable design parameters is higher. This supposes an exponential explosion that makes common sense useless. In this paper we propose a way to help in the difficulty balance of a game using Formal Concept Analysis (FCA), a mathematical method for data analysis, knowledge representation and information management. Specifically, we apply FCA in the inspection of betatesters plays logs. We claim that the conclusions we extract with FCA can be useful in several areas of game tuning. The outline of the paper is as follows. Section 2 introduces the game designer work, and formalises it in order to serve as a basis for the rest of the paper. Section 3 describes FCA, and section 4 the way we use it for helping the game design. These exposed ideas are apply in Section 5 in a concrete example involving the well known Tetris game. Section 6 analyses where our method is applicable. Finally, Section 7 presents some conclusions and ends the paper.

2

The Game Designer Work Formalised

The effort to defeat opponents or to overcome levels has important effects on the entertainment perceived by players. Novice or casual players usually prefer challenging but beatable enemies, while strong players enjoy difficult ones. Game designers have traditionally added games with several difficulty levels. At the beginning of the game session, users choose the category where they feel they belong to, and game opponents adjust their difficulty accordingly. However, the parameters the game changes depending on that level are stated by game designers using their intuition. This is an easy task only in very simple games. For example, it seems clear that in the well-known minesweeper game altering board size or the number of mines affects the complexity of the game. So, there is a dependency between the size of a board and its difficulty. In non trivial games, this link between game parameters and game complexity may not be so clear. Game designers have to find out, usually guided by their intuition, which parameters determine the difficulty. As a first step forward an atomatic tool for helping in this game balance, in this section we will formalise the task of configuring the different difficulty levels using a mathematical notation. The first decision to be taken is the number of difficulty levels the game will have. In our formalization, we will consider L as the set of de different levels,

for example: L = {easy, normal, hard} As it has been told previously, the designer is able to change different game parameters to establish the difficulty level. For example, in a first person shooter (FPS), the designer may alter the number of enemies in one map, or the accuracy of the player gun. From now, we will name P the set of the design parameters that can be changed. Every member of P (pi ) has a specific domain, D(pi ). For example, the domain of the number of enemies in a map takes its values from positive natural numbers: D(number of enemies) = N+ The designer task is to establish, for each element li ∈ L, a value for all the parameters pi ∈ P . That can be seen as defining the functions: ti : L → D(pi ) or, grouping all them together: t : L → D(p1 ) × . . . × D(pn ) that is a function that receives the difficulty level and provides a tuple with the value of all the game parameter for it. As a mnemonic, the function name t comes from designer task. As said before, this association between difficulty level and values in the design parameters has been traditionally done in a ad hoc way, using the intuition and common sense. For simple games, this is enough, but it is quite scarce when the complexity increases. In that case, it is common practise to use focus groups in the initial stages of the development. A focus group consists in a set of people with different videogame backgrounds who is faced to a preliminary version of the project. Game designers look over the shoulder of the testers, taking notes that can help them to understand how people play their game. The version of the game itself is in charge of saving a big amount of log information to later off-line processing. We will denote this group of testers as T . They initially estimate their own skill in the game based in their experience with similar games and preferences. Assuming that the different available categories are what we previously called L, we will designate: s:T →L as the function that links each tester with her skill level. The logs created by the program used by the focus group annotate different measures about the way each tester evolves in the game. In our running FPS

example, some of them could be the number of killed enemies, time to overcome a level, final health state or the shot average to hit somebody. We will denote the set of measures as M . Each value in M belongs to a specific domain D(mi ). The formalisation of these logs consists on a group of functions fi relating each tester with a measure mi : fi : T → D(mi ) or, grouping all of them in a generalized funcion returning a tuple: f : T → D(m1 ) × . . . × D(mn ) All this information is collected and analysed by designers. They must use their knowledge about statistics to filter the logs (f ) and extract the interesting information. Their conclusions would be, for example, that novice FPS players need a big amount of shots to kill an enemy, or very experienced gamers can overcome a level without kill anybody. These conclusions are objective to some extent, except due to the fact that the testers have arranged themselves in the different skill groups. In this points, it’s worth remembering that the final task of the designers is to specify the t function, relating difficulty level (L) and adjustable game parameters (P ). Therefore, using the previously acquired conclusions, designers can decide, for example, that initial levels should have a big amount of ammo, but it should be scarce in the harder ones in order to force gamers to play as the experts do. Again, this t is determined using common-sense. A hypothesis is hidden in all this process. Measured values in the focus group (M ) are supposed to be, in some way, dependent with the different changeable design parameters P . In other words, for a specific gamer gi , the value of f (gi ) would be different if any parameter in P is changed in the game used to test it. In that sense, examples of useless measures in a FPS would be the number of unnecessary jumps, or the times the player pauses the game. The information collected by the logs is potentially huge. In order to help game designers to use them, some kind of data analysis may be used. Our method consists on using Formal Concept Analysis (FCA) to process them and giving hints to be applied while balancing the game. To make this paper self-contained, next section describes FCA, that we will use in Section 4.

3

Formal Concept Analysis

Formal Concept Analysis (FCA) is a mathematical method for data analysis, knowledge representation and information management. It was invented by Rudolf Wille [11] and during the last two decades it has been applied in numerous applications in different domains, like psychology, medicine, linguistics and computer sciences among others. In general, FCA may be useful in knowledge discovery in databases [9]. In previous papers [3, 8, 2] we have used FCA

as a particular and very adequate technique to organize and discover knowledge embedded in Case Based Reasoning (CBR) applications. FCA can be applied to any collection of items described by properties and provides a way to identify groupings of objects with shared properties. FCA applied on a data set provides an internal sight of the conceptual structure and allows finding patterns, regularities and exceptions among the cases. In FCA, data is structured into formal abstractions called concepts. These formal concepts have the property that they form a concept lattice, ordered by a subconcept-superconcept relation. As we explain in next subsection, besides conceptual abstractions, FCA also allows to elicit the attribute co-appearance knowledge between the properties describing the objects. First, we describe the basis of the FCA technique. See [4] for a concise textbook treatment. Second, we illustrate FCA with a simple example of experience indexing in the Tetris case study that is used in Section 5.

3.1

Context, concept lattices and rules

In FCA, a formal context is defined as a triple hG, M, Ii where there are two sets G (of objects) and M (of attributes), and a binary (incidence) relation I ⊆ GxM , expressing which attributes describe each object (or which objects are described using an attribute), i.e., (g, m) ∈ I if the object g carries the attribute m, or m is a descriptor of the object g. When the sets are finite, the context can be specified by means of a cross-table. When we have to deal with numbers we use standard techniques for discretizing numeric attributes [12] as we do in Section 5. With a general perspective, a concept represents a group of objects and is described by using attributes (its intent) and objects (its extent). The extent covers all objects belonging to the concept while the intent comprises all attributes (properties) shared by all those objects. With A ⊆ G and B ⊆ M the following operator (prime) is defined as: A0 = {m ∈ M | (∀g ∈ A)(g, m) ∈ I} B 0 = {g ∈ G | (∀m ∈ B)(g, m) ∈ I} A pair (A,B) where A ⊆ G and B ⊆ M , is said to be a formal concept of the context hG, M, Ii if A0 = B and B 0 = A. A and B are called the extent and the intent of the concept, respectively. It can also be observed that, for a concept (A, B), A00 = A and B 00 = B, which means that all objects of the extent of a formal concept, have all the attributes of the intent of the concept, and that there is no other object in the set G having all the attributes of (the intent of) the concept. The set of all the formal concepts of a context hG, M, Ii is denoted by β(G, M, I). The most important structure on β(G, M, I) is given by the subconcept - superconcept order relation denoted by ≤ and defined as follows:

b i e w w