Thesis Andrew 2009.Pdf

誌誌誌謝謝謝

椰林大道上的椰子樹葉，隨風擺動，在兩歲的乙澤眼中，是一株株高大的電風扇片，被不知名的力量推得轉啊轉的，帶著老婆與孩子，在七月的校園裡面閒逛，陽光照在臉上熱辣生疼，托乙澤的福氣，終於有機會悠閒地佇足在圖書館前介紹他阿爸的學校，在

還沒辦法分辨左右兩邊是哪個系的系館之前，啊，我要畢業了，是該感謝眾人的時候到了。

母親大人: 這幾年都沒好好地陪您，愧疚多些。浩華老師: 是好好老師，沒有脾氣，可以忍受我ㄧ個學期只出現面前一次。昇瑋老師: 真可惜沒到遊戲產業。（空格）（偶而還是會想稱呼為寬達老師）。智冠王總: 感謝當初支持我進修。鈊象電子及唯舞團隊: 提供遊戲的相關資訊。

ＤＣＩ的大夥們: 婉芬、懷寧、佳鳳、書賢、冠華...，在這幾年靠你們吃吃喝喝。同學們: 靠你們怪奇的魔術，可以開懷暢笑，靠你們靈通的消息，可以順利畢業。

最後該感謝的是，在身邊轉啊轉的波波還有乙澤，讓我知道揮汗如雨的七月午後，也可以有甜入心中的微笑。

i Contents

誌謝 ...... i 中文摘要 ...... v 英文摘要 ...... vii

1 Introduction 1

2 Related Work 4

3 FPS Game Bot Detection 6 3.1 FPS Games ...... 6 3.2 Quake 2 and Its Game Bots ...... 6 3.3 Data Collection ...... 7 3.3.1 Human Traces ...... 7 3.3.2 Bot Traces ...... 8 3.3.3 Trace Summary ...... 9 3.4 Discriminative Analysis ...... 9 3.4.1 Aggregated Navigation Pattern ...... 10 3.4.2 Individual Trajectories ...... 12 3.5 Bot Detection Scheme ...... 13 3.5.1 Feature Extraction ...... 13 3.5.2 Classiﬁcation ...... 19 3.6 Performance Evaluation ...... 19

4 Rhythm Game Bot Detection 21 4.1 Rhythm Games ...... 21 4.2 Dancing Online ...... 21 4.2.1 Normal Mode ...... 22 4.2.2 Rhythm Mode ...... 23 4.2.3 Beat Mode ...... 24 4.3 Dance Online Game Bots ...... 24 4.4 Data Description ...... 24 4.5 The Recording Program ...... 25 4.5.1 Data Declaration ...... 25 4.5.2 Recording Program Design ...... 28 4.5.3 Data Collection ...... 29 4.6 Discriminative Analysis ...... 33 4.7 Bot Detection Scheme ...... 35 4.7.1 Time Spent Based ...... 35 4.7.2 Pressure-Error Based ...... 37 4.8 Performance Evaluation ...... 37

ii 4.8.1 Time Spent Based ...... 37 4.8.2 Pressure-Error Based ...... 38

5 Conclusion 42

References 45

iii List of Figures

3.1 A screen shot of Maze War...... 7 3.2 A screen shot of Quake 2...... 8 3.3 Presence locations of all players...... 10 3.4 Game play trajectories of a human player and bot players...... 12 3.5 The distribution of features related to ON/OFF periods...... 14 3.6 The distribution of features related to movement pace...... 15 3.7 The distribution of features related to movement path...... 17 3.8 The distribution of features related to turn movement...... 18 3.9 Classiﬁcation accuracy between human and bots...... 20 3.10 Classiﬁcation accuracy between four types of players (human and three bot programs)...... 20

4.1 The screen shot and dance platform of Dance Dance Revolution. . . . 22 4.2 A normal mode screen shot of Dancing Online...... 22 4.3 A rhythm mode screen shot of Dancing Online...... 23 4.4 A beat mode screen shot of Dancing Online...... 23 4.5 The setup dialog of DCO...... 25 4.6 Texture of Dancing Online...... 29 4.7 The time relationship between player’s traces and standard keys. . . . 32 4.8 The probability distribution of 16 combinations...... 35 4.9 Interval time to error rate of 16 arrow combinations in players’ traces. 36 4.10 16 Types of Players’ Conditional Probability Distribution...... 38 4.11 Player’s Consistency Analysis...... 39 4.12 Bot with Normal distribution...... 40 4.13 Quantiﬁcation of Pressures...... 40 4.14 Players’ Error Rate under Diﬀerent Pressures...... 41

iv List of Tables

3.1 Trace summary ...... 9

4.1 An example of Ti time stamp ...... 30 4.2 An example of player’ trace ...... 31 4.3 Game experience of players ...... 31 4.4 Traces summary ...... 33

v 中中中文文文摘摘摘要要要

近年來，多人線上遊戲成為了網路上非常普遍的休閒活動，但隨著多人線上遊戲的蓬勃發展，玩家欺詐的行為也變得越來越常見，其中最嚴重的，要算是使用俗稱 bot 的自動化機器人程式了，原因是 bot 使用者不需付出對應的努力，即可獲得不合情理的獎

勵，一般而言，遊戲社群間是不認同 bot 的存在的。然而想要辨識 bot 使用者，然後加以反制是困難的，原因是 bot 本來就是被設計來在遵循遊戲規則下模仿玩家行為，其行為模式與真正玩家相仿。以往遊戲經營者嘗試以肉眼偵測遊戲機器人程式的方式，

經常產生誤判案例糾紛可見一般，因此目前遊戲產業期望藉助一些軟體技術，嘗試來偵測 bot 的存在，以增加判定的準確率。這些偵測技術大致上有幾種類型，第一種是在遊戲進行中，中斷玩家進行方式進而分析玩家類型，缺點是干擾玩家進行遊戲的順暢。第二種反制方式是在遊戲進行中，監測系統是否有 bot 程式存在，這種方式前提是假設機器人程式是必須依附於客戶端遊戲程式，且多半只針對特定功能者。例如 FPS 遊戲中，專司瞄準的機器人程式，其缺點是失去一般性。因此在本論文中，我們對兩種線上遊戲類型分別提出對應的 bot 偵測方式。

第一種為俗稱 FPS 的第一人稱射擊遊戲，提出基於遊戲中人物移動軌跡的方法偵

測 FPS 遊戲中的機器人程式，它可以被應用於所有具有移動軌跡類型遊戲的一般性技術。透過真實玩家數據分析，我們得知，真實玩家移動的軌跡特性與那些機器人程式是非常不同的，雖然遊戲機器人程式竭力模仿真實玩家的行為，但是因為玩家行為是非常難以仿造，這點是我們的主要理論基礎。我們採用了 Quake 2 作為實際研究案例，根據評估真實玩家的紀錄顯示，這種偵測方法在以 200 秒為一觀測單位下，可以達到 95% 以上的準確性。

第二種針對節奏類型遊戲，提出一種基於壓力與錯誤率的方法來偵測跳舞機類型遊戲

的機器人程式。它也是一個可以被應用於此類跳舞機類型遊戲的一般性技術，理論基礎

vi 是，因為玩家會隨著節拍快慢與按鍵組合形成的壓力大小，與按鍵時間與按鍵值與出錯的機率成正比，也因資料簡單，因此此類 bot 非常容易透過學習真實玩家的方式，發展反制 bot 偵測的技術。然而，除非 bot 得知我們的數學式實際參數值，否則反制我們的偵測，也是十分困難的。我們採用了唯舞獨尊此款多人線上遊戲作為我們的實際研究案例，由於至目前為止尚未找到對此類型遊戲 bot 偵測的論文，因此我們是第一個可以用來偵測節奏類型 bot 的論文。

關關關鍵鍵鍵詞詞詞: 欺詐行為偵測, 線上遊戲, 安全性, 分類, 玩家行為

vii 英英英文文文摘摘摘要要要

In recent years, online game has become one of the most popular Internet activities, but cheating activity, such as game bots, has increased as a consequence. Generally, the gamer community disagrees with the use of game bots, as bot users obtain unreasonable rewards without corresponding efforts. However, bots are hard to detect because they are designed to simulate human game playing behavior and they follow game rules exactly. Existing detection approaches either interrupt the players’ gaming experiences, or assume game bots are run as standalone clients or assigned a specific goal, such as aim bots in FPS games. Therefore, we separately propose game bot detection approaches according to two different types of online games. 1) A trajectory-based approach to detect FPS game bots. It is a general technique that can be applied to any game in which the avatar’s movement is controlled directly by the players. Through real-life data traces, the result shows that the trajectories of human players and those of game bots are very different. In addition, although game bots may endeavor to simulate players’ decisions, certain human behavior patterns are difficult to mimic because they are AI-hard. Taking Quake 2 as a case study, we evaluate our scheme’s performance based on real-life traces. The result shows that the scheme can achieve a detection accuracy to 95% or higher, given a trace of 200 seconds or longer. 2) A pressure-error-based approach to detect rhythm game bots. It is also a general technique that can be applied to any rhythm game in which the errors increase the dependance on pressure from the game speed and key combinations.

viii Theoretically, the bot can ﬁght back by learning the real player’s behaviors, but without our arguments of formula, the bot is hard to do that. The study case is Dancing Online. Up to now, we have not found any paper about rhythm game bots detection, so we believe that this paper is the ﬁrst one for rhythm game bots detection.

Key words: Cheating Detection, Online Games, Quake, Dancing Online, Secu- rity, Supervised Classiﬁcation, User Behavior

ix Chapter 1

Introduction

In recent years, online game has become one of the most popular Internet activities. However, as the population of online gamers has increased, game cheating problems, such as the use of game bots, have become more and more serious. Game bots are automated programs with artificial intelligence for players to use on different purposes. In MMORPGs (Massively Multiplayer Online Role Player Games), players can save a great deal of time by using bots to perform repetitive tasks, such as slashing low-level monsters, or fishing in a river to master the avatar’s fishing skills. In FPS (First-Person Shooter) games and rhythm games, users can employ bots to play in place of themselves in order to get high scores and gain a reputation in the community. Generally, the gamer community disagrees with the use of game bots, as bot users obtain unreasonable rewards without corresponding efforts. However, game bots are hard to detect because they are designed to simulate human game playing behaviors and they follow the game rules exactly. Some bot detection studies [7,19] propose that using CAPTCHA tests during a game can determine whether an avatar is actually controlled by a person or not. Although it is effective, it interrupts the game and degrades players’ feelings of immersion in the virtual world [10,14]. Alter- natively, passive detection approaches, such as schemes based on traffic analysis [1,2] and schemes based on avatars’ shooting accuracy in FPS games [20], can be used. The former approach assumes that a game bot works as a standalone client, and the

1 latter is only valid for detecting aim bots in shooting games. The genre of MMOG is very varied, so we only select two very popular types of online games and try to propose the general approaches separately to detect each bots. 1) A trajectory-based approach for all genres of games where a player controls the avatar’s movement directly which is based on the avatar’s movement trajectory during a game. 2) A pressure-error-based approach for rhythm games where a player follows rhythm to hit the corresponding key which is based on the pressure and error rate relationship of the player during a game. The rationale of the first approach is that the trajectory of the avatar controlled by a human player is hard to simulate. Players who control the movement of avatars base on their knowledge, experiences, intuition, and a great deal of information provided in the game. Since human decisions are not always logical and efficient, modeling and simulating realistic movements is still an open question in the AI field. To distinguish human players from game bots efficiently, we analyze the trajectories of both player types and distinguish between the trajectories according to their spatial and temporal characteristics. We choose Quake 2 as our case study because it is a classic and popular FPS game, and there are many real-life human traces available on the Internet. Therefore, we can use such traces to validate our proposed scheme. The rationale of the second approach is that the pattern of mistake can be very different between two players. Players hit corresponding keys by their sense of rhythm, vigor, experiences, and the tendency to make errors, which makes the traces of two players very different. However, it is easy for bots to fight back by learning real player’s behaviors. Thus, we try to model a pressure-to-error formula, of which the bots cannot fight back without our arguments. We choose Dance Online as our case study.

The contribution of this paper is two-fold. 1) We propose a trajectory-based approach for detecting game bots [3,4]. It is a general model that can be applied to any game in which the avatar’s movement is controlled by the players directly. Using

2 real-life human traces, the performance evaluation results show that the scheme can achieve a detection accuracy of 95% or higher when the trace length is 200 seconds or longer. Because it is difficult to simulate human players’ logic when they control game characters, we believe that this approach has the potential to distinguish between human players and automated programs and thus merits further investigation. 2) We propose a pressure-based approach for detecting rhythm game bots. It is a general model that can be applied to any rhythm game in which the players only hit a key by rhythm. Using bot-like recorder, we collect the traces of bots and players. Up to now, since we have not found any paper about rhythm game bots detection, we believe that this is the first paper for rhythm game bots detection. The remainder of the paper is organized as followed. Chapter 2 contains a review of related works. In Chapter 3, we focus on trajectory-based approach. First, we introduce our game case study, Quake 2, and describe the game trace collection methodology. Then, we analyze the similarities and differences between the trajectories of different types of players. After that, we propose an identification scheme and demonstrate its ability in terms of the distribution of discriminative features. In the end of the section, we evaluate the performance of the proposed scheme with the consideration of the trace length. In Chapter 4, we focus on the pressure-to- error approach. First, we introduce our rhythm game case study, Dancing Online, and later describe the game trace collection methodology. Then, we analyze the similarities and differences between the traces of different types of players. After that, we propose an identification scheme and demonstrate its ability in terms of the distribution of discriminative features. In the end of the section, we evaluate the performance of the proposed scheme. Finally, in Chapter 5, we summarize our conclusions.

3 Chapter 2

Related Work

Golle and Ducheneaut proposed using CAPTCHA (Completely Automated Pub- lic Turing Test to Tell Computers and Humans Apart) tests [19], either software- based or hardware-based, to prevent bots from playing online games [7]. Currently, the most widely used CAPTCHA tests rely on the ability of humans to recognize randomly distorted text or images. However, this approach distributes the cost of bot detection among all users, including legitimate players, as the tests inevitably interrupt players’ adventures and reduce their sense of immersion in the virtual world. Understandably, legitimate players may dislike such tests as they may feel they are suspected of cheating. This could be one of the reasons that password-book-based anti-copy mechanisms for PC games have not gained wide acceptance. However, CAPTCHA might be the best last line of defense if automatic bot identification mechanisms, such as the proposed traffic-based scheme, are used. In other words, passive detection schemes can be used initially to identify suspected cheating among thousands of players online. Then, CAPTCHA tests can be applied to the suspects only. Recently, anti-cheating software programs, such as PunkBuster and GameGuard, have been widely deployed in online games. Such software is bundled with game clients, so it cannot be uninstalled even if the game client has been removed. It works by hiding in the game client process, monitoring the entire virtual memory space (to prevent modification of the game’s executable images), blocking suspected

4 programs that might be hacker tools, and blocking certain API calls. This kind of software can detect nearly all plug-in tools that attach to a game client program to inspect or modify game states when the game is running. Unfortunately, it cannot stop the widespread use of standalone bots, including the bot series we study in this paper. The reason is that these anti-cheating software programs are host-based, so they must be installed on players’ PCs to be eﬀective. Standalone bots, on the other hand, can function without clients, and it is unlikely that anti-cheating tools would be installed on PCs where the bots are running. This claim is strongly supported by the fact that game bots are still active in the games protected by PunkBuster or GameGuard, e.g., Quake (PunkBuster) and Lineage1 (GameGuard).

1http://boards.lineage2.com/showflat.php?Number=573737

5 Chapter 3

FPS Game Bot Detection

3.1 FPS Games

FPS (First-person shooter) game is a game genre which centers the gameplay around gun or projectile weapon-based combat through the first person perspective. It integrates advanced 3D graphics elements, hardware development and multiplayer games. The first person shooter game has been traced as far back as Maze War, developed by Spasim from 1973 to 1974 [15]. The screen-shot is shown in Fig. 3.1. In the 21st century, the first-person shooter game is one of the most commercially viable and fastest growing game genre.

3.2 Quake 2 and Its Game Bots

Quake 2 is a famous FPS (First-Person Shooter) game that was developed by id Software [9]. The player adopts the role of a particular character and shoots his enemies via the user interface shown in Fig. 3.2. Multiple players can participate in a game simultaneously, and they can cooperate to complete a mission. However, the death-match mode, in which each player tries to kill as many other participants as possible, is much more popular. Quake 2 was nominated as “The Best Game Ever” by PC Gamer in 1998, and was sold over one million copies [8]. One reason for its popularity is that it is easy to customize, and a large number of maps, player models,

6 Figure 3.1: A screen shot of Maze War. textures, and sound eﬀects are available via the Internet. The game has been ported to many platforms other than PCs, for example, Nintendo 64, Playstation, Amiga PowerPC, and Xbox 360.

There are many game bots available for Quake 2. That is because id Software released the source code of Quake 2, trying to attract scholar researches, but, also generated a lot of bots, which have made the bot detection more diﬃcult. For this study, we select three most popular bots from Quake 2 for trace collection, namely

CR BOT 1.14 [13], Eraser Bot 1.01 [6], ICE Bot 1.0 [12].

3.3 Data Collection

3.3.1 Human Traces

Quake 2 supports a game-play recording function that keeps track of every action and movement, as well as the status of each character and item throughout the

7 Figure 3.2: A screen shot of Quake 2. game. With a recorded trace, one can reconstruct a game and review it from any position and angle desired via VCR-like operations. Players often use this function to assess their performance and combat strategies. Moreover, experienced players are encouraged to publish their game-play traces as teaching materials for novice gamers and thereby build a reputation in the community. To ensure that our game traces represent the diversity of Quake players, we only use traces that players had contributed voluntarily. The human players’ traces were downloaded from the following archive sites: GotFrag Quake1, Planet Quake2, Demo Squad3, and Revilla Quake Site4. We restrict the traces to the map The Edge, one of the most well-known levels of death-match play. On this map, the only goal is that each player should kill as many other players as possible, until the time limit is reached. Because short traces contain little information, we only collect traces longer than 600 seconds.

3.3.2 Bot Traces

To collect the game bot traces, we set up an experiment on a Quake server and run a number of game bots to ﬁght each other. The experimental setup is as followed: 1http://www.gotfrag.com/quake/home/ 2http://planetquake.gamespy.com/ 3http://q2scene.net/ds/ 4http://www.revilla.nildram.co.uk/demos-full.htm

8 Table 3.1: Trace summary

Name Num Mean Total Active 1 Human 93 2 hour 203.5 hour 91% 2 CR 24 19 hour 448.8 hour 91% 3 Eraser 15 20 hour 296.4 hour 94% 4 ICE 18 20 hour 358.8 hour 67%

1. Launch a server for 2 hours.

2. In each game, a random selection of 2–6 bots are arranged to ﬁght each other.

3. The game trace is recorded at the server with the serverrecord command.

4. The game’s catch-the-flag mode is turned off, so the game bots keep fighting against each other until the server shuts down. The cheating mode is also disabled.

5. The AI levels of CR Bot and Eraser Bot are randomly set from 0 to 9 and 0 to 3 respectively.

3.3.3 Trace Summary

We collect 1, 306 hours of traces in total, as shown in Table 3.1. In CR Bot and Eraser Bot, all human players and bots are active most of time (≥ 90%). Less activity in ICE Bot because it often remains idle in some places waiting for an opportunity to ambush other players.

3.4 Discriminative Analysis

In this section, we compare the avatar trajectories of human players and game bots. First, we compare the navigation patterns of the two player types and consider their individual trajectories. We then identify the most signiﬁcant discriminative characteristics of the respective trajectories and incorporate them into the proposed bot identiﬁcation scheme.

9 (a) Human players (b) CR Bot

Figure 3.3: Presence locations of all players.

3.4.1 Aggregated Navigation Pattern

We construct the aggregated navigation pattern of each player type by plotting all the observed coordinates in all traces of the particular player type on a graph, as shown in Fig. 3.3. The areas of high density in each figure are the places that players visit more frequently, while the sparse areas represent buildings or other types of obstacles that players cannot pass. The figures show that the game level is formed by squares, plazas, and narrow corridors. This arrangement is designed specifically for death-match play, as the winding routes provide cover for players to hide, and the narrow corridors lead to intense fighting if players confront each other in these places. We observe that, even though all the movement traces were collected on the same map, the navigation patterns of different player types are dissimilar. We summarize the differences below.

1. Human players tended to explore all areas on the map; thus, Fig. 3.3(a) shows the most complete terrain of the level. In contrast, the routing algorithms of

game bots may have had diﬃculty navigating to some places, so they never visited some parts of the map. For example, the bottom left-hand corner of

10 the CR Bot navigation map in Fig. 3.3(b) does not indicate the presence of bots.

2. To reduce the probability of being attacked, human players normally avoid open spaces. Therefore, in Fig. 3.3(a) we observe that human players avoided the plaza in the middle of the map, and stayed in the surrounding corridors instead. This is indicated by the high density of plots in the corridors. In contrast, game bots often stay in the central plaza, probably because it occupies

a large space and it is easy to get everywhere from this area.

3. Even though human players spend most of their time in narrow areas and conﬁned rooms, there are large variations in their trajectories. There are two reasons for this phenomenon. 1) The width of the main routes is quite large. Rather than stay in the middle of a route, players move irregularly within the limited space. This may be due to players’ preferences; hence, some players may move along the wall of the path, while others may walk straight, unless the avatar is blocked by a wall or other obstacles. 2) As ﬁghts may occur

anytime-anywhere, human players often move strategically to dodge current or potential attacks. On the other hand, we find that different game bots adopt very different movement patterns over the routes. The movement paths of CR Bot and Eraser Bot (Fig. 3.3(b) and Fig. 3.3(c) respectively) are dense and easy to see. This suggests that these bots tend to follow exact movement patterns when moving through the same corridor. In contrast, ICE Bot (Fig. 3.3(d)) exhibits a nearly uniform distribution over all possible points on the map. This implies that its routing algorithm decides the avatar’s direction rather than its exact movement pattern, so that the probabilities of all points on the route

are roughly equivalent.

Clearly, there are substantial diﬀerences between the aggregated navigation patterns of human players and those of each game bot because the bots’ routing patterns are very diﬀerent from the movement behavior exhibited by human players.

11 (a) Human players (b) CR Bot

Figure 3.4: Game play trajectories of a human player and bot players.

3.4.2 Individual Trajectories

Having analyzed the aggregated navigation patterns of the different player types, we now examine their individual trajectories. We manually select a representative trace for each of the four player types (human player plus three game bots). The avatar trajectory of each selected trace is shown in Fig. 3.4. Even if we only observe one trace at a time, the difference between the player types is still apparent. Our observations about the aggregate navigation patterns still hold. Specifically, the narrower a place is, the higher the probability that human players will stay in that place, which is opposite to the game bots’ behavior patterns. Moreover, human players’ trajectories contain much more irregularity and sharp turns. There are two possible explanations for this: 1) irregular moves reduce the chances of being attacked from behind; and 2) human decision-making can be erratic and thus may not be logical all the time. A human player may change his/her mind any time and adjust the character’s pace and direction because of the so-called

“sixth sense.” In contrast, bots’ trajectories are characterized by straight and long paths.

12 The differences between the movement patterns of human players and game bots provide the conceptual framework for our trajectory-based bot detection scheme. Even though bot developers may counter the detection algorithm by training bots to mimic human behavior, we argue that certain human behavior traits are difficult to emulate. While game bots’ fixed movement patterns can be made more flexible by incorporating randomness into the navigation logic, evaluating whether or not a place is “dangerous” is AI-hard. For example, human players tend not to stay in the central plaza on the map and thereby reduce the probability of being attacked; however, it is difficult for game bots to “sense” the environment and “decide” to avoid staying in the plaza. Therefore, we believe that bot detection schemes based on avatar trajectories would be robust to bot developers’ countermeasures.

3.5 Bot Detection Scheme

Our objective is to classify human players and game bots efficiently and accu- rately. To this end, we integrate the spatial and temporal differences in the trajectories of avatars controlled by different player types to develop a bot identification scheme. In this section, we first describe the set of discriminative features extracted from the avatar trajectories, and then explain how we use the features to classify game bots and human players.

3.5.1 Feature Extraction

Given a segment of a trajectory, {xt, yt}, 1 ≤ t ≤ T , we extract the following features from this two-dimensional time series.

1. ON/OFF Activity

First, we note that avatars in the game play do not move all the time. Sometimes they may stop to check if any opponents are around, wait for opponents to enter an area, wait for regeneration of their weapons or ammunition, or simply take a rest.

13 On Period Mean On Period SD 0 50 150 250 0 50 100 200

Human CR Eraser ICE Human CR Eraser ICE

Off Period Mean Off Period SD 5 10 15 20 0 5 15 25 35

Human CR Eraser ICE Human CR Eraser ICE

Figure 3.5: The distribution of features related to ON/OFF periods.

The alternate moving and idle behavior forms an ON/OFF movement pattern. We define ON periods as consecutive periods of movement longer than 1 second, and OFF periods as the remaining time frames. The duration and frequency of ON/OFF periods are decided by the players’ styles and the bots’ AI logic. For example, aggressive players may keep moving all the time, while cautious players may stay in one place to monitor their surroundings. Therefore, we define four features based on ON/OFF activity: the mean and standard deviation of ON periods, and those of OFF periods. Fig. 3.5 shows the distributions of the four features. The mean and standard deviation of human players’ ON periods are significantly higher than those of game bots. This indicates that human players are more aggressive as they tend to move all the time. In addition, the mean and standard deviation of human players’ OFF periods are longer than those of bots, which implies that human behavior is more irregular and unpredictable in that they may wait for a longer time after a long move.

The ﬁgure shows that human players and game bots diﬀer in terms of ON/OFF activity. Hence, we believe that the four features based on these activities could be useful for bot detection.

14 Pace Mean Pace SD 5 10 15 20 25 30 2 4 6 8 10 12

Human CR Eraser ICE Human CR Eraser ICE

Pace (>10) SD Teleportation 2 4 6 8 10 0.00 0.04 0.08 Human CR Eraser ICE Human CR Eraser ICE

Figure 3.6: The distribution of features related to movement pace.

2. Pace

In games, avatars are generally allowed to move at different speeds and in different ways, such as running, slow walking, step-by-step walking, lateral shifting, and moving backwards. In addition, players can stop the current movement and proceed with another movement in different direction in sub-seconds; therefore, the resulting avatar movements can be highly variable. One simple way to characterize the dy- namics of an avatar’s movement is by the pace of its movements. We define the pace as the displacement of an avatar’s coordinate in one second, and extract the mean and standard deviation of the pace as two features. We find that the paces of most avatars are generally small, although they can be large occasionally. To characterize the variability of paces when players move fast, we also define the “large pace SD,” which is the standard deviation of paces larger than 10 units. In addition to normal movements, players may teleport their avatars to a remote place instantly through a teleportation spot. Teleportation may also be used when an avatar dies. It will be transferred to the rebirth spot so that its life points can be recharged. We detect teleportation occurrences by computing if the offset in one second is longer than 60 units and define the feature “teleportation rate” as the average count of teleportation occurrences recorded in one second.

15 Fig. 3.6 shows the distribution of the four features related to the movement pace and teleportation. Although the means of the paces of different player types are dissimilar, the variations are not large. This shows that the four player types have different but consistent micro-movement behavior in small time scales. The standard deviation of the pace also has large discriminability, where that of human players and Eraser Bot have similar magnitude. The large standard deviation of the pace, on the other hand, exhibits great discriminability, which indicates that human players have even larger pace variability when they move fast. Finally, CR Bot and Eraser Bot have very low teleportation frequency. In contrast, human players have moderate teleportation frequency. Moreover, their variance is high because human players have different preferences when using teleportation spots and players get killed at different rates.

3. Path

We also deﬁne the following features to characterize the detailed trajectories of avatars in a game.

Lingering. We consider whether players “lingered” in a small area during a specific time period. For an avatar at (x, y) at time t, if its distance from (x, y) was always less than d during the period (t, t + p), we say that the avatar was lingering during (t, t + p), given the parameters (d, p). We arbitrarily set d = 30 seconds and p = 300 units, as we find that different parameters do not affect the classification performance significantly.

Smoothness. The “smoothness” feature determines whether an avatar moves in straight or zig-zag patterns. Assume an avatar is at (x1, y1) at time t1 and at

(x2, y2) at time t2. We deﬁne the smoothness as the number of times the character moves across the line (x1, y1) − (x2, y2) during the period (t1, t2). As the line

(x1, y1) − (x2, y2) indicates the shortest route between the two points (x1, y1) and

(x2, y2), crossing the line implies that the player is moving ineﬃciently. This may be because he is attempting to dodge gunﬁre, switch to another target, or simply

16 Linger Frequency Linger Length 15 20 25 30 35 0.01 0.03 0.05

Human CR Eraser ICE Human CR Eraser ICE

Smoothness Detourness 5 10 15 0.80 0.90 1.00

Human CR Eraser ICE Human CR Eraser ICE

Figure 3.7: The distribution of features related to movement path. due to players’ habits or bots’ routing algorithms.

Detour. We define another feature “detour” to quantify the effectiveness of user movements. If an avatar is at (x1, y1) at time t1 and at (x2, y2) at time t2, we compute the detour by dividing the length of the movement by the effective offset of an avatar during the period (t1, t2). The distributions of the above features are plotted in Fig. 3.7. The graph shows that the linger frequency and duration of human players are significantly less than those of game bots. This is reasonable because lingering in a place for a long time is a dangerous, as the player may be noticed and induce opponents’ fire. The smoothness of human players is the lowest of the four player types, which supports the intuition that human players’ movements are the most irregular and unpredictable. The detour feature shows that Eraser Bot moves very inefficiently in terms of the avatar’s effective offset. In contrast, the movements of human players are relatively more efficient. We suspect this is because human players tend to move away from current positions to another place efficiently even though they may move irregularly and strategically; thus, the resulting avatar trajectory exhibits both unpredictability and efficiency which seem contradictory.

17 Turn 30 Turn 60 0.0 0.2 0.4 0.6 0.0 0.2 0.4 0.6 Human CR Eraser ICE Human CR Eraser ICE

Turn 90 Turn Angle 0.0 0.2 0.4 60 70 80 90 110 Human CR Eraser ICE Human CR Eraser ICE

Figure 3.8: The distribution of features related to turn movement.

4. Turn

Our ﬁnal set of features is based on the frequency and amplitude of how avatars change direction. Our rationale is that each time an avatar changes direction, the magnitude of the change should be dependent on player conventions and bot routing algorithms.

Assume an avatar is at (x1, y1) at time t, at (x2, y2) at time t + p, and at

(x3, y3) at time t + 2p. If the angle between two vectors (x2 − x1, y2 − y1) and

(x3 − x2, y3 − y2) is greater than a, we determine that a turn with angle a occurred. We define three features to denote the frequency of turns with angles 30◦, 60◦, and 90◦, respectively. In addition, we define a feature called the “turn angle” to denote the average angle change for all direction changes greater than 30◦. Fig. 3.8 shows the distributions of the turn-related features. We observe that the four player types change direction at different rates no matter how we define the minimum degree of a direction change. Notably, the turn frequency of human players is the highest for the 30◦ angle and becomes relatively lower for the 90◦ angle. In addition, the average turn angle of human players is the lowest among the four types, which indicates that human players tend to adjust their directions continuously and slightly.

18 3.5.2 Classiﬁcation

We apply a supervised classification framework to train a classifier, which we use to determine whether a segment of an avatar’s trajectory belongs to a human player or a game bot. The classifier we adopt is the naive Bayesian classifier without the kernel density estimation. We evaluate the performance of trajectory classification in the next section.

3.6 Performance Evaluation

In this section, we evaluate the performance of our proposed bot detection scheme on the collected traces. First, we evaluate whether our scheme can distinguish between human players and game bots, by using the classifier to perform 10-fold cross-validation. In real-life scenarios, the trace length plays an important role because it determines how quickly a game bot can be detected. Thus, we evaluated the performance of our scheme on different traces lengths, as shown in Fig. 3.9. The graph shows that the detection accuracy is higher than 90%, even when the trace length is as short as 100 seconds. Longer traces yield better accuracy. To determine which category of features yields the highest accuracy, we plot the classification performance for each category of features. The results indicate that the features related to the movement pace, direction changes, and ON/OFF periods all yield good results, while path-related features only exhibit good discriminability when the trace length is 800 seconds or longer.

Furthermore, we perform a player-type classification; that is, we not only determine whether a character is controlled by a human player or a bot program, but also identify the bot program used if appropriate. The results are shown in Fig. 3.10. The classification accuracy of the player types is even better than that of the human-bot scenario when the trace length is longer than 200 seconds. With a trace length of 500 seconds or longer, our scheme yields a classification accuracy of

98% or higher. However, in this setting, individual feature categories, except those

19 Accuracy

ON/OFF features Pace features Path features Turn features All features 0.0 0.2 0.4 0.6 0.8 1.0

100200 300 400 500 600 700 800 900 1000 Observation time (sec) Figure 3.9: Classiﬁcation accuracy between human and bots. Accuracy

ON/OFF features Pace features Path features Turn features All features 0.0 0.2 0.4 0.6 0.8 1.0

100200 300 400 500 600 700 800 900 1000 Observation time (sec) Figure 3.10: Classiﬁcation accuracy between four types of players (human and three bot programs).

related to movement paces, exhibit low discriminability when they are applied to the classiﬁcation separately.

20 Chapter 4

Rhythm Game Bot Detection

4.1 Rhythm Games

The original core gameplay of rhythm game involves the player moving his or her feet to a set pattern in time according to the rhythm or the beats of a song. The speed of the arrows are divided by 1/4 notes, 1/8 notes, and so on, up to about 1/32 notes. When the scrolling arrows overlap the stationary ones, the player must step on the corresponding arrows on the dance platform, and the player is given a judgement for their accuracy (Marvelous, Perfect, Great, Good, Boo/Almost,

Miss/Boo)1. The ﬁrst rhythm game is DDR (Dance Dance Revolution), produced by Konami [18].The screen shot is shown in Fig. 4.1.

4.2 Dancing Online

The DO (Dancing Online) is a famous rhythm online game that was developed by International Games System (IGS) [11]. In the game community website, it is always in the top 10 discussed game in the forum [17]. The DO uses arrow keys on the keyboard instead of those on the dance stage. The DO can be divided into the normal-mode for beginners, the beat-mode and rhythm-mode for expert players.

The following paragraph explains each gameplay.

1http://en.wikipedia.org/wiki/Dance Dance Revolution

21 (a) The screen shot of DDR. (b) The dance platform of DDR.

Figure 4.1: The screen shot and dance platform of Dance Dance Revolution.

Figure 4.2: A normal mode screen shot of Dancing Online.

4.2.1 Normal Mode

This mode is very different from others. There is a ball floating from left to right across the screen, and there are 1 to 9 indicators underneath at same time. Before the ball reaches the stationary region, the player has to hit the corresponding arrow keys on the keyboard and hit “SPACE” key to get the scores. According to the difference between hit-time and reach-time, the scores are perfect (±10 ms), great (±30 ms), good (±50 ms), cool (±80 ms), miss (±100 ms). The screen-shot is shown in Fig. 4.2.

22 Figure 4.3: A rhythm mode screen shot of Dancing Online.

Figure 4.4: A beat mode screen shot of Dancing Online.

4.2.2 Rhythm Mode

This mode is similar to original DDR mode, but the diﬀerence is that the indicators and the arrow keys are altered into “Z”, “X”, “<” and “>” for the convenience of the keyboard layout. The screen shot is shown in Fig. 4.3. According to the difference between hit-time and reach-time, the scores are as perfect (±10 ms), great (±30 ms), good (±50 ms), cool (±80 ms), miss (±100 ms), and bad if a wrong key is hit.

23 4.2.3 Beat Mode

In beat mode, there is a track bar at the bottom of the screen, in which all the indicators are ﬂoating from left to right over time. When they arrive in the stationary region “W” on the right of the bar, the player has to hit the corresponding arrow keys on the keyboard. According to the diﬀerence between hit-time and reach-time, the scores are as perfect (±10 ms), great (±30 ms), good (±50 ms), cool (±80 ms), miss (±100 ms), and bad if a wrong arrow key is hit. The screen shot is shown in Fig. 4.4.

4.3 Dance Online Game Bots

So far, the only available bot of Dancing Online is “DCO” [5]. This bot helps the player hit the corresponding arrow keys automatically to get the high scores. We can download DCO from its web page. The default functionality can fully support the normal mode but only provides ﬁve minutes per hour for the beat and rhythm modes. You may pay for a fully support version. The funny thing is, the Dancing Online itself is free (item mall). To anti-detect by other players or the system, the DCO supports a customized error time value for the player to adjust the hit-time and makes the scores unstable, which looks like a real player. We name it ADV

(Anti-Detection Value). In DCO document, the suggested value of ADV is 700 nanosecond, the best value to prevent any detection and to get the best scores in the game. The DCO screen shot is shown in Fig. 4.5. We set ADV to 700 ns, and the score distribution is from “perfect” to “great”.

4.4 Data Description

Dancing Online was not designed for any trace preservation mechanism, which makes the data collection more diﬃcult. Adding this feature into the game is not possible due to two main reasons as followed:

24 Figure 4.5: The setup dialog of DCO.

1. the game has existed in the market for a long time. To modify the source code will need to re-test and thus reduce the proﬁt.

2. the service providers are prohibited to provide any existing data stored in the server to the third party according to the terms and conditions of contracted agreement.

Therefore, we develop a bot-like program, and use it to record players’ traces from the client side.

4.5 The Recording Program

4.5.1 Data Declaration

Any single record includes two fields, (Key, T ime). The Key field stands for the directions, that is “UP”, “DOWN”, “LEFT” and “RIGHT”. The T ime field is the timing when Key is hit. We define some terms for the latter usage:

1. Indicator key Ki: the arrow displayed on the track.

2. Player key Kp: the arrow key hit by the player.

25 3. Indicator reach time Ti: the perfect timing that the Kp must hit on a key.

4. Player time Tp: the timing that the player hits on a key.

We divide our recording program implementation into two parts: The ﬁrst part is the code that we use for to record traces, and the second is the method of injecting the code into DO address space. First of all, we must describe some features of Dancing Online before we implement the recording program.

1. Direct3D 9.0c as a graphic engine.

2. DirectShow as a music player.

3. GetCurrentPosition interface of IMediaSeekingcount as a timer. The Ti and

Tp both are computed with this interface.

4. Window message: WM KEYDOWN to get Kp.

5. There are 3 kinds of Ki: single hit, key-hold, and repetitive hits.

6. The available audio ﬁle format can be either WMA or MP3, and each has a

magic number to adjust the Ti.

7. To describe the music speed, bpm (beats per minute) is applied. All the values are distributed from 59–240 bpm.

8. Diﬃcult levels: easy, normal, hard and top.

9. Regardless of either bpm or diﬃcult level, the shortest Ki interval time is no less than 1/16 of the quarter note. Take the fastest music beat 240 bpm as an example, the shortest interval time is 15.6 ms. The longest interval time is up to tens of seconds and usually occurs either in the prelude or the intermezzo.

10. The screen refresh rate is 30 frames per second, which means every 33 ms the screen will be updated.

26 11. According to the diﬀerence between Ti and Tp, the game system will determine the scores, which are perfect (±10 ms), great (±30 ms), good (±50 ms), cool (±80 ms) and miss (±100 ms). And two other special scoring rules are shown as followed:

(a) bad, if Ki 6= Kp;

(b) silence drop, if |Tp − Ti| > 100 ms.

12. Ti is encrypted in a predefined file of each song. When the music starts, the corresponding file is decrypted by the game system, and is stored in a hidden folder. When the music ends, the file is deleted to avoid the hacker from

learning the format. Since the ﬁle relates to Ti date collection, we pick the

most important data, Ti time stamp, to describe its signiﬁcant features. The

partial of Ti time stamp is shown in Table 4.1.

(a) Ti (ms), the time when a player must hit an arrow key.

(b) Ki code, the game levels of the types of hitting, including single hit, key- hold, and repetitive hits, and the code also applies to rhythm mode. The value is shown as decimal, while we explain each in hexadecimal as shown below:

i. 0x0001, when the music begin;

ii. 0x0002, when each music bar begin;

iii. 0x0004, single hit in EASY level;

iv. 0x0008, repetitive hits in EASY level;

v. 0x0010, key-hold in EASY level;

vi. 0x0020, single hit in NORMAL level;

vii. 0x0040, repetitive hits in NORMAL level;

viii. 0x0080, key-hold in NORMAL level;

ix. 0x0100, single hit in HARD level;

x. 0x0200, repetitive hits in HARD level;

27 xi. 0x0400, key-hold in HARD level;

xii. 0x0800, single hit in TOP level;

xiii. 0x1000, repetitive hits in TOP level;

xiv. 0x2000, key-hold in TOP level.

Features 1 to 4 are related to the methods of the recording program to get the

Ki, Kp, Ti, and Tp, while others are related to the detection scheme design.

4.5.2 Recording Program Design

Because DO does not have the trace preservation mechanism, we design a re- coding code to inject into DO address space to create such mechanism. The most frequently used function in Windows OS is CreateRemoteThread. However, it has a limitation that it can only accept an injection code up to 4K, which is deﬁnitively not enough for our recording code. Thus, in the practice, we move the recording program code into DLL so we can implement a 4K DLL loader into CreateRemoteThread to retrieve the recording DLL in DO address space. Furthermore, we adopt Detours library [16] to hijack corresponding functions, which is described above as features 1 to 4, with recording DLL.

The following are the ﬂows of recording process:

1. Use Process32First and Process32Next in Win32 API functions to get DO process image.

2. Use CreateRemoteThread to inject DLL loader into DO address space.

3. Use Detours library to hijack the wndproc function to get Kp.

4. Use Detours library to hijack the DirectShow related functions get the Tp.

5. Use Detours library to hijack the Direct3D related rendering functions to get

Ki.

28 Figure 4.6: Texture of Dancing Online.

6. Use Detours library to hijack the CreateFile function to get the Ti.

7. Wait till the DO ends.

In theory, we could use image recognition to to get Ki, but it is not possible in practice. There are two reasons: First, it is time consuming and inﬂuences DO performance, which loses the precision of Ti and Tp. Second, The image exists on VRAM (Video RAM) and when we fetch the data from VRAM to system memory, we lose the precision of Ti and Tp. Therefore, we propose to hijack Direct3D rendering functions. The image renders with screen coordinate, texture coordinate and a texture, which can be retrieved from rendering functions. Thus, we can simply match the texture coordinate onto the texture and we can get Ki. This is O(1) problem. The texture is shown as Fig. 4.6.

4.5.3 Data Collection

Human Traces

To distinguish the difference between the real players and bots, we invite six real players to play different bpm and/or different game levels, and use recording program to record the traces of every player. The experimental setup is as followed:

29 Table 4.1: An example of Ti time stamp

Index Ti (ms) Ki Code Rhythm Code 0 0 2 0 16 2,448 2 0 31 4,744 1 0 32 4,897 2 0 48 7,346 2 0 64 9,795 2 0 80 12,244 2 0 96 14,693 2 0 112 17,142 2 0 128 19,591 2342 11979028 130 19,897 0 4718592 132 20,204 2340 1100000000 135 20,663 2048 4194304 136 20,816 2336 4277256 137 20,969 2048 8388608

1. The players are appointed to selected game levels.

2. In each level, the players are assigned to diﬀerent bpm and songs.

3. The players’ traces are recorded by the recording program.

And we also invite another 10 real players for player-type classification. Their game experiences are described in Table 4.3. For classification, the song selection step is a little different. We identify 20 songs in each game levels.

Bot Traces

1. The ADV (Anti-Detection Value) of DCO is set from 0 to 700 manually.

2. The multi-players mode is turned oﬀ to prevent other players from joining the game, so the DCO will not be detected.

3. Select the game level manually because DCO does not implement this func-

tionality.

4. Enable random select mode of DCO.

30 Table 4.2: An example of player’ trace

Time (sec) Type Key Value 20.00799942 user RIGHT 20.06299973 pred RIGHT 20.50900078 user LEFT 20.56500053 pred LEFT 20.69799995 user RIGHT 20.81500053 pred RIGHT 20.99799919 user UP 21.06599998 pred UP 21.79700089 user UP 21.81900024 pred UP 21.97400093 user RIGHT 22.06900024 pred RIGHT 22.30200005 user DOWN

Table 4.3: Game experience of players

Player Rank Game Experience bruce beginner one month jackal beginner one month kaiyan beginner one months wei beginner two months colin intermediate several months compact intermediate several months evans intermediate several months superbbs intermediate several months su expert two years yubo expert several years

5. Enable auto-run mode of DCO and bot starts to play automatically.

6. The game traces are recorded by the recording program.

Trace Mapping

The ideal mapping between Ki and Kp is “one-by-one”. However, while playing, players always try to correct the Kp if he/she misses a key, or hits multiple keys, which result in two or more Kp to one Ki. The typical pattern is shown as Fig. 4.7.

Basically, here are two approaches to map Kp and Ki. 1) Best match: select the

31 Figure 4.7: The time relationship between player’s traces and standard keys.

smallest time diﬀerence (Kpi+1). 2) First match: select the ﬁrst key within the threshold of Ki (Kpi). We select the approach 2 as our matching algorithm, because it is the game scoring rules. The matching algorithm is shown as follow:

1. Sort indicators according to Ti ascendant into S.

2. Sort plays traces according to Tp ascendant into P .

3. For each (Ki,Ti) record I in S do

(a) for each (Kp,Tp) record J in P do

i. if J.Tp − I.Ti < −100 do;

A. remove J from P ;

B. break;

ii. if J.Tp − I.Ti > 100 do break;

iii. else do

A. pair (K,P );

B. remove J from P ;

C. break.

32 Table 4.4: Traces summary

Type Bot Data Set 1 Data Set 2 song 247 333 800 records 85,097 114,350 306,619

Data Summary

We collected 580 song traces for distinguishing data, and 800 song traces for player-type classiﬁcation, which are shown in Table 4.3.

4.6 Discriminative Analysis

This section contains the details of the characteristics of bot and the players so we can design the recognition scheme accordingly later. In addition, we filter out the traces which either players or bot do not occur. For example, there is no trace related to key-up after bot performs, so the key-up trace that appears in the players record is filtered out. Besides, it is not possible for players to behave like bot to hit the continuously with extreme speed, above 20 times per second or higher, so the two additional key-hold and repetitive hits are removed as well. Also, because the score rules are different among different rhythm games, for general purpose, we too remove the score attribute.

After the traces are mapped, given the name P, they should comprise of Ki,Kp,Ti,Tp.

If the player miss a key, Ki,Kp fields assign to NA. We now define some characteristics of P for the differentiation.   |P.Ki − P.Kp|, if P.Ki = P.Kp; different time: dt(P ) = (4.1)  NA, otherwise.

  1, if P.Kp = NA; miss: miss(P ) = (4.2)   0, otherwise.

33   1, if P.Ki 6= P.Kp; incorrect arrow-key: incor(P ) = (4.3)  0, otherwise.    1, if miss(P)=true or incor(P)=true ; error: error(P ) = (4.4)  0, otherwise.

For the relationship between of two adjacent P Pi, Pi+1, we deﬁne it as:

interval time: intv(Pi,Pi+1) = Pi+1.Ti − Pi.Ti. (4.5)

For the relationship between two P without Kp = NA, Pi, Pj, we deﬁne it as:

time spent: ts(Pi,Pj) = |Pi.Tp − Pj.Tp|. (4.6)

When we observe the behaviors of real-plays and the traces, we ﬁnd out that the result of “time spent” and error rate is inﬂuenced by previous Kp. For example, if the value of “time spent” is small or the Ki combination is in a pattern, error rate will increase or dt(P ) will change dramatically. We assume that it is because the players are under the stress of “time spent” and key combination. There are 16 key combinations: (UP, UP), (UP, DOWN), (UP, LEFT), (UP, RIGHT), (DOWN, UP), (DOWN, DOWN), (DOWN, LEFT), (DOWN, RIGHT), (LEFT,

UP), (LEFT, DOWN), (LEFT, LEFT), (LEFT, RIGHT), (RIGHT, UP), (RIGHT, DOWN), (RIGHT, LEFT), (RIGHT, RIGHT), We plot CDF (cumulative probability distribution) by interval time to time spent. It is shown in Fig. 4.8 We ﬁnd out that the distributions of the combinations are all diﬀerent. Some are centered and some are scattered, which can prove our assumption.

Observing the behaviors of players, we ﬁnd out that they make more mistakes when the interval time is shorter than 400 ms or under certain key combinations. We plot the error rate to interval time of 16 combinations of all players in Fig. 4.9. We also notice that, when interval time becomes longer, the players feel more relaxed.

34 Figure 4.8: The probability distribution of 16 combinations.

The players make less mistakes.

4.7 Bot Detection Scheme

Based on time spent and error rate, we propose an approach to classify the real players and bot.

4.7.1 Time Spent Based

Based on our assumption of the time spent and error rate is affected by previous delayed or missed hit, this paper adopt the difference of time spent to construct the detection scheme. We detect the influence of previous hit, so there are 16 key combinations. To define all the combination, we denote (new: Ki, pre: Ki+1). For example, the previous hit is “↑” and the new hit is “←” so we denote it as

35 Figure 4.9: Interval time to error rate of 16 arrow combinations in players’ traces.

(new :←, pre :↑). The probability distribution functions is as

f(t|current intput: ←, previous input: ↑). (4.7)

Since we do not know the probability distribution of bot and players population , we adopt Kolmogorov-Smirnov test (KS test) to detect the diﬀerence of the behaviors of each. KS test is to compare two samples to tell them if they are from the same probability distribution function or not. In another word, we can distinguish if they are the traces of players or bot. The test statistic of KS test is

D1,2 = sup|F1(x) − F2(x)|. (4.8)

Due to the multinomial experiment of the scheme (16 combinations), we adopt

Bonferroni method to make sure any single conﬁdence coeﬃcient is under 0.003

(α = 0.05/16 ' 0.003). If any single conﬁdence coeﬃcient α still equals to 0.05,

36 overall conﬁdence coeﬃcient will increase to 1 − (1 − 0.05)16 ' 0.5599.

4.7.2 Pressure-Error Based

From the perspective of the players behaviors influenced by the stress, there are two types of errors: first, the probability, which is easy to measure and simulate. Second, the stress, which is abstract so it is difficult to quantify. However, we try to utilize the conditional probability function to predict the model by parameters of interval time, key combination and time spent of traces. Since every player behaves similar under the same pressures, when we quantify the stress model and compare to players’ error rate, if there is a huge difference, we can assume that the player uses bot or the game is played by another player.

4.8 Performance Evaluation

4.8.1 Time Spent Based

In Time Spent Mode analysis, we compare the characteristics of bot and the real players and plot them as Fig. 4.10. Due to the confidence coefficient, α = 0.003, within the 16 combinations, if any p-value is smaller than α, we can assume that the behaviors are different. Also according to the experiment and simulation, we find out that they are different probability distributions. From the figures we can easily tell the distribution is different.

Players behave differently under different time. They progress by learning and practicing, which results in misjudgement. To avoid the attribute, we assume that every player behaves stable in a short term. Then, we use the scheme to trace different time periods of the same player. We test same player’s traces by different time segment. The result is shown as Fig. 4.11. We find that all the p-values are greater than α, which means the games are played by the same player. It proves that our scheme is consistent.

In the result, our schema can identify the bot and real players perfectly, that

37 Figure 4.10: 16 Types of Players’ Conditional Probability Distribution. is the original bot is too simple. So we try to emulate the next two possible bot generations. Assuming that bot is able to learn the player’s time spent, and calculate the mean and standard deviation by the directions combinations, then it may ﬁght back our detection scheme. Therefore, we use normal distribution to simulate the time spent. The result is shown as Fig. 4.12. We can still tell the diﬀerence.

The detection scheme has one disadvantage. If bot-designer ﬁnds out the conditional probability functions and familiars with the probability and statistics, he/she will ﬁght back our scheme.

4.8.2 Pressure-Error Based

We apply conditional probability function to model the pressure. The result is plotted as Fig. 4.13. We find out that the trend is not much different from a real player. According to the figure, we analyze the error rates to pressures of different

38 Figure 4.11: Player’s Consistency Analysis. players’ performance and plot them as Fig. 4.14. We find out that different players have different patterns under stress, which can distinguish between bot and a real player as well as among different players. Because there is no certain stress error model, the bot-designer can not fight back without our formula.

39 Figure 4.12: Bot with Normal distribution.

Figure 4.13: Quantiﬁcation of Pressures.

40 Figure 4.14: Players’ Error Rate under Diﬀerent Pressures.

41 Chapter 5

Conclusion

In our paper, we propose two kinds of bot detection schemes for two types of games. For FPS game, we propose trajectory-based approach to detect bot. It is a general technique that can be applied to any game in which the avatar’s movement is controlled by the player directly. Our analysis of real-life traces shows that the trajectories of human players and game bots are very dissimilar. The performance evaluation results show that our bot detection scheme can achieve a detection accuracy of 95% or higher when the trace length is 200 seconds or longer. Because it is difficult to simulate human players’ behavior when controlling game characters, we believe that our method has the potential to distinguish between real players and bots, and thus merits further investigation. For rhythm games, we propose time spent mode to distinguish bot and real players efficiently. If bot-designer finds out the conditional probability functions and familiars with the probability and statistics, he/she will fight back our scheme. Thus, we propose error mode to fix such problem. Unless the bot-designer knows our formula, he/she will not be able to fight back. Up to now, we have not found any paper about rhythm game bots detection, so we believe that this paper is the first one for rhythm game bots detection.

43 Bibliography

[1] Kuan-Ta Chen, Polly Huang, and Chin-Laung Lei. Game traﬃc analysis: An MMORPG perspective. Computer Networks, 50(16):3002–3023, 2006.

[2] Kuan-Ta Chen, Jhih-Wei Jiang, Polly Huang, Hao-Hua Chu, Chin-Laung Lei,

and Wen-Chin Chen. Identifying MMORPG bots: A traﬃc analysis approach. In Proceedings of ACM SIGCHI ACE’06, Los Angeles, USA, Jun 2006.

[3] Kuan-Ta Chen, Andrew Liao, Hsing-Kuo Kenneth Pao, and Hao-Hua Chu.

Game bot detection based on avatar trajetory. In Proceedings of IFIP ICEC 2008, 2008.

[4] Kuan-Ta Chen, Hsing-Kuo Kenneth Pao, and Hong-Chung Chang. Game bot identiﬁcation based on manifold learning. In Proceedings of ACM NetGames 2008, 2008.

[5] DCO. http://www.play55.net/.

[6] Ryan Ridah Feltrin. Eraser Bot 1.01, May 2000. http://downloads.gamezone.com/demos/d9862.htm.

[7] Philippe Golle and Nicolas Ducheneaut. Preventing bots from playing online

games. Computers in Entertainment, 3(3):3–3, 2005.

[8] Id Software: id History. http://www.idsoftware.com/business/history/.

[9] id Software, Inc. http://www.idsoftware.com/.

44 [10] Said Ila, Dick Mizerski, and Desmond Lam. Comparing the eﬀect of habit in the online game play of australian and indonesian gamers. In Proceedings of the Australia and New Zealand Marketing Association Conference, 2003.

[11] International Games System CO.,LTD. http://www.igs.com.tw/.

[12] jibe. ICE Bot 1.0, 1998. http://ice.planetquake.gamespy.com/.

[13] Mike Malakhov. CR Bot 1.15, May 2000. http://arton.cunst.net/quake/crbot/.

[14] Thomas P. Novak, Donna L. Hoﬀman, and Adam Duhachek. The inﬂuence of

goal-directed and experiential activities on online ﬂow experiences. Journal of Consumer Psychology, 13(1):3–16, 2003.

[15] Spasim (1974) The First First-Person-Shooter 3D Multiplayer Networked Game. http://www.geocities.com/jim bowery/spasim.html.

[16] The website of Detours. http://research.microsoft.com/en- us/projects/detours/.

[17] The website of Gamer. http://www.gamer.com.tw/.

[18] The website of Konami. http://www.konami.co.jp/en/.

[19] Luis von Ahn, Manuel Blum, Nicholas J. Hopper, and John Langford.

CAPTCHA: Using hard AI problems for security. In Proceedings of Eurocrypt, pages 294–311, 2003.

[20] S. Yeung, J.C.S. Lui, J. Liu, and J. Yan. Detecting cheaters for multiplayer games: theory, design and implementation. Proc IEEE CCNC, 6:1178–1182.