Chapter 3 Preliminaries
3.3 Area of Interest
An Area of Interest (AoI) is the area of concern to a player (in MMOG). Each avatar has its own AoI which is defines by its visibility scope. An avatar only can interact (fighting, trading or do nothing) with the entities which are in its AoI scope.
In other words, avatars can see avatar A’s behavior when they are in the avatar A’s AoI. An area with several overlapping AoIs will become a hotspot that may generate large load in MMOGs. We can prevent load increasing by limiting the size of a
11
hotspot. However, limiting the size of the hotspot would be equal to limit the scope of the interaction between players. This approach will decrease the players’ game experience. Therefore, in this paper, we do not consider limiting the size of a hotspot.
12
Chapter 4
MMOG Load Modeling
There are three main types of resources used for MMOGs: CPU, memory, and network bandwidth [10]. Table II shows definition of notations that are used in our load models. We assume that the number of active avatars per VM in the same game zone is almost the same. We enhance Nae et al.’s load model [10] by considering player behavior. In this way, we can improve resource over-allocation.
4.1 CPU load model for a VM
For modeling the CPU load of a VM in a game zone, we summarize three factors of CPU time which are , , and for an MMOG server. We model the CPU time as the time sending and receiving messages from a VMi to each client (active avatar) as
The CPU time spent for processing state updates from the VMi to the other VMs is
∑ (
,
)
The CPU time spent for computing the different behavior between different active avatars is
∑ 𝑜𝐼𝑘 𝑘
𝑎𝑣𝑎𝑡𝑎𝑟𝑘∈{𝐴𝐸𝑖}
13
Thus, the total CPU time spent in one tick is
Finally, we define the CPU load function as:
𝑜
Processing time for a VM to process an event message from a client Update time of entity states received from/sent to another VM B The set of four kinds of possible behavior types
Computation time of a behavior type, ∈
𝑘 Computation time for avatar k with behavior type b
The amount of memory needed for a VM to store the state of one avatar
The amount of memory needed for a VM to store the state of an NPC entity
𝑎
The amount of memory a VM used for running the actual game engine with no game world loaded and no client connected
𝑟 The amount of memory a VM used with the game world being played
The amount of data received from a client
𝑡 The amount of data sent to a client
𝑡 The amount of data exchanged between VMs for updating a single entity state
14
4.2 Memory load model for a VM
The memory load model is less complex than the CPU load model; we can define the memory load function for each VM as follow:
𝑜 (∑ ) 𝑎 𝑟
𝑀𝑣 ,
where 𝑀𝑣 represents the amount of memory available in a VM. Each VM requires the state information of all active avatars and NPCs/bots in the same Game Zone in order to synchronize each VM.
4.3 Network load model for a VM
The incoming network bandwidth usage for each VM in a game zone is as Therefore, we define the overall network load as follows:
𝑜 𝐸 𝑥 ( 𝐷
𝑊 , 𝐷 𝑡 𝑊 𝑡),
where 𝑊 and 𝑊 𝑡 denote the input and output network bandwidths, respectively.
4.4 Complete load model for a VM
According to the above three load model, we derive the overall load for each VM by choosing the maximum load from each individual resource load shown as follows:
𝑜 𝑉𝑀 𝑥( 𝑜 , 𝑜 , 𝑜 𝐸 )
15
Chapter 5
Proposed Player Behavior-based Resource Allocation
5.1 PB-RA architecture
Figure 4 shows the system architecture for our proposed Player Behavior-based Resource Allocation (PB-RA), which contains two parts: Main Server and Game Zones. An MMOG has a Main Server and several Game Zones. The Main Server is responsible for storing monitoring history records and according to these records to predict resource requirements for each game zone with the helping of a Neural Network-based predictor to ensure the experiences of players who are in a virtual machine (VM). Each Game Zone is connected to the Main Server to get the information for maintaining the game world. The following is a brief description of each module. History Storage stores the game data collected by Zone Handler. Neural Network-based Predictor predicts the number of players for each behavior in each zone via the neural network. Load Model calculates the server load of next time slot, which will be sent to Zone Handlers for adjusting number of VMs. Communication facilitates the exchange of messages between Game Zones or forwards VM adjusting information to Zone Handlers. Video Streamer is a component which transforms gaming graphics to streaming video. Zone Handler is a main controller to communicate with Main Server and to synchronize VMs and to process necessary computations of a game zone. If the overall load exceeds the capacity provided by current VMs, Zone Handler will add a Mirror VM to support the Zone Handler.
16
5.2 Neural network-based predictor
A neural network (NN) is a simulation of biological neural network [14]. It simulates human’s brain by mathematical statistics techniques. The neural network connects many simple artificial nodes which called “neurons.” Neural networks have following features: parallel process, fault tolerance, associative memory, solution
History Storage
Figure 4. Proposed PB-RA Architecture.
17
optimization, etc [14].
In this paper, we choose a NN-based predictor because that predictor is based on the most suitable prediction method that was observed in [9], [10], [17]. We ran our NN-based predictor on MATLAB which is a high-level language and interactive environment for numerical computation, visualization, and programming [16]. Figure 5 shows such a network with 24 network inputs and one network output. We input the number of players for each behavior from time slot 1 to time slot 24 and predict the number of players for each behavior at time slot 25. The neural network has a hidden layer, which has 10 neurons. Neurons in the hidden layer and the output layer perform calculations based on the following equations, respectively:
ℎ 𝑓(∑ 𝑥 𝑤 ,
18 the bias of the output layer. In addition, 𝑓(𝑥) is either a log-sigmoid transfer function for the hidden layer neurons, or a linear transfer function for the output layer neurons.
We used this neural network-based predictor to predict the number of players in each behavior.
5.3 PB-RA flowchart for a zone
In our approach, each zone initializes a suitable VM size according to statistical results of history data. In general, the VMs are able to meet the requirements of players and guarantee the response time that satisfies the quality of player experiences.
Figure 6 shows the flowchart of PB-RA. At first, Main Server obtains the number of players in this zone and stores the collected data to History Storage. After that, Main Server determines the zone type. If the zone type is one of Dungeon, Raid or Battlefield, the NN-based predictor only predicts the number of players in this zone.
In these types of zones, avatars always combat with each other, and they require the highest real-time experience. Therefore, we always assume the player behavior is
“Fighting” so that satisfy QoS requirements. If the zone type is Home City or Normal Map, the NN-based predictor will predict the number of players for each behavior.
Then we will assign different weights for different behavior types and the priority
19
order is “Fighting” > “Questing” > “Trading” > “AFK” that is based on the measures in WoW. Next, Main Server derives the maximum load according to our load model described in Chapter 4. Afterwards, Main Server passes the load information to Zone Handler.
After receiving the load information form Main Server, Zone Handler checks the load of each VM in the Game Zone. If the predicted load is greater than the capacity of total VMs in this Game Zone, Zone Handler will add a mirror VM to lighten the load of Game Zone. If the predicted load is smaller than the current capacity of VMs, Zone Handler will decide which working VMs can be merged. Finally, if the number of working VMs in Game Zone is greater than two, Zone Handler will synchronize the VMs’ state of avatars and monster information.
Start End
Figure 6. The flowchart of PB-RA.
20
Chapter 6 Evaluation
In this chapter, we first describe how to collect game data, show simulation setup and then discuss simulation results.
6.1 Data collection
In our simulation, we used World of Warcraft (WoW) as a case study, which is the most famous MMOG in the world; according to statistics, it has 10.2 million subscribers in February 2012 [1]. We collected game data from WoW clients for two weeks, from April 22 to May 7, and the collected data are recorded every five minutes.
The details of our game data collection are described in the following. First, we chose the map named Valley of the Four Winds as our collecting area, which is a popular map for avatars of level-90. Because this map is abundant in natural resources which are requirements for producing equipment, the avatar density and behavior diversity are higher than the other maps. Next, we distributed 21 WoW clients over this map, and log the state information of each client by typing the /combatlog command.
Combatlog is a kind of log, which records combat actions and results within the radius of 200 yards from each WoW client, as Figure 7 shows. Combatlog may also includes results of profession activities of nearby characters [22]. Last, we parsed and analyzed all the combat log derive the number of players for each behavior.
21
6.2 Simulation setup
Table III shows our simulation setup. Although parsing the Combatlog can derive the number of players for each behavior, the location of each player is still unknown.
Therefore, we randomly generated the location for each player at the beginning to distribute avatars uniformly in a game zone and update the direction and mobile distance for each avatar in each timeslot to simulate a real game zone environment.
According to the game data we collected in History Storage, we predicted the player behavior for each avatar in the next timeslot by using a neural network-based predictor in MATLAB. We applied the prediction results to our load model in order to predict the number of VMs required in the next timeslot. Then, we used ColudSim which is a famous cloud simulation tool to simulate PB-RA. In our simulation, we assumed one VM can support 31 avatars [18], each VM had 512 MB memory and 10
Figure 7. The distribution of WoW clients.
22
Mbps bandwidth, and VM startup time was 100 seconds [19]. The radius of AoI was set to 50 yards which is the default vision range in WoW. We implemented our load model introduced in Chapter 4 on CloudSim and follow the flowchart of PB-RA to adjust number of VMs used.
6.3 Simulation results
In our simulation, we collected the game data from WoW clients for two weeks from April 22 to May 7. However, a full week is enough to reflect the ecological cycle because the story events will be reset every week in WoW. Therefore, we only used one week data in our simulation. According to our load models in Chapter 4, we compare the proposed PB-RA with the methods considering number of players and interaction of players [10] in terms of total resource requirement, number of VMs used, resource over-allocation rate, and resource under-allocation rate in a WoW’s map which is called Valley of the Four Winds. The calculation of the represent the resource over/under allocation rate is as follows:
δ 𝑛𝑣 ( 𝑟 ) 100% − 𝜆 𝑎 , Table III. Simulation setup.
Game data Collected from World of Warcraft (WoW)
(version 5.2.0) Prediction technique Neural network
Prediction tool MATLAB (version 7.11.0)
Evaluation period 2013/04/22 15:43 ~ 2013/05/07 15:36 Cloud simulation tool CloudSim 3.0
VM startup time 100 sec. [19]
VM capacity 31 avatars [18]
VM memory 512 MB (CloudSim default value)
VM incoming bandwidth 10 Mbps (CloudSim default value) VM outgoing bandwidth 10 Mbps (CloudSim default value)
Radius of AoI 50 yards in WoW
23
{𝑖𝑓 𝛿 ≥ 0, 𝑜𝑣𝑒𝑟- 𝑙𝑙𝑜𝑐 𝑖𝑜𝑛 𝑖𝑓 𝛿 < 0, 𝑢𝑛 𝑒𝑟- 𝑙𝑙𝑜𝑐 𝑖𝑜𝑛
where 𝑛𝑣 ( 𝑟 ) is the predicted number of VMs required and 𝜆 𝑎 is the actual usage of resources. We calculated 𝜆 𝑎 via using actual number of players for each behavior calculated by our load model introduced in Chapter 4. In Figure 8 and Figure 9, we show the total resource requirements and number of VMs in the Valley of the Four Winds of WoW, repectively. In both figures, we can see that the required number of VMs will vary with time. The number of VMs required achieves the minimum at 6:00 a.m. and the maximum at 8:00 p.m. every day. Furthermore, adjusting the number of VMs dynamically is better than that statically. In addition, in terms of the number of VM need in a zone, the proposed PB-RA is 55% lower than the method only considering number of players and 33% lower than the method considering interaction of players [10].
Figure 8. Total resource requirements in Valley of the Four Winds of WoW.
0
08:00 08:00 08:00 08:00 08:00 08:00 08:00
Considering
Total Resource Requirement (%)
Time
24
Finally, we evaluate the resource over-allocation rate and resource under-allocation rate of the proposed PB-RA. Resource over-allocation means that the allocated resources exceed the resource requirements of a zone and resource under-allocation means that the allocated resources do not meet the resource requirements of a zone. Figure 10 shows the over-allocation rate of PB-RA is lower than the other methods. The result shows that PB-RA can reduce 74% of resource under-allocation rate and the percentage of events with the under-allocation rate
Figure 9. Number of VMs used in Valley of the Four Winds of WoW.
0
08:00 08:00 08:00 08:00 08:00 08:00 08:00
Number of VMs
25
higher/lower than the average under-allocation rate per VM.
Figure 10. Over-allocation of each method.
0
08:00 08:00 08:00 08:00 08:00 08:00 08:00
Considering
Figure 11. Number of under-allocation events of each method.
0 Number of under-allocation events (total 4256 records)
(1.66%) (1.71%)
26
Table IV. The detailed information of resource under-allocation rate.
Average
Higher than average
Lower than average
Considering Number of Players 0 0 0
Considering Interaction of Players [10] 4.08% 35%
(26/75)
65%
(49/75) Considering Behavior of Players
(proposed PB-RA) 3.97%
35%
(28/79)
65%
(51/79)
27
Chapter 7 Conclusion
7.1 Concluding remarks
We have presented a Player Behavior-based Resource Allocation (PB-RA) scheme for MMOG clouds. The behavior of players is classified into four types:
Fighting, Trading, Questing and AFK. We used WoW as a case study to illustrate the proposed PB-RA that is applicable to MMOGs and each behavior type results in a different load. We predict the number of players for each behavior type in one map through a neural network-based predictor and measure loads generated from different player behavior types. As a result, we can predict total resource requirements more accurately for players with different behavior types in the map. That is, we can allocate cloud resources more efficiently. Experiment results have show that the proposed PB-RA can reduce 74% of resource over-allocation compared to the method that only considers number of players, and 50% compared to the method that considers interaction of players [10] as well. Moreover, in terms of the number of resource under-allocation events the proposed PB-RA is no more than 1.05 times compared with the method that considers interaction of players [10].
7.2 Future work
In this paper, we collected the game data only from MMOG clients. In the future, we may obtain the real data of game servers to have more accurate evaluation. In addition, we will implement the Video Streamer to achieve real cloud gaming.
28
References
[1] “MMOGs Subscription,” [Online]. Available: http://mmodata.net/.
[2] “Cloud Gaming,” [Online]. Available:
http://en.wikipedia.org/wiki/Cloud_gaming/.
[3] D. T. Ahmed and S. Shirmohammadi, “A Microcell Oriented Load Balancing Model for Collaborative Virtual Environments,” in Proc. IEEE Conference on Virtual Environments, Human-Computer Interfaces and Measurement Systems, VECIMS’08, pp. 86- 91, July 2008.
[4] D. T. Ahmed and S. Shirmohammadi, “Uniform and Non-Uniform Zoning for Load Balancing in Virtual Environments,” in Proc. IEEE International Conference on Embedded and Multimedia Computing, EMC’10, pp. 1-6, Aug.
2010.
[5] B. V. D. Bossche, B. D. Vleeschauwer, T. Verdickt; F. D. Turck, B. Dhoedt, and P. Demeester, “Autonomic Microcell Assignment in Massively Distributed Online Virtual Environments,” Journal of Network and Computer Applications, vol. 32, no. 6, pp. 1242-1256, Nov. 2009.
[6] C. E. B. Bezerra, J. L. D. Comba, and C. F. R Geyer, “A Fine Granularity Load Balancing Technique for MMOG Servers Using a KD-Tree to Partition the Space,”
in Proc. VIII Brazilian Symposium on Games and Digital Entertainment, SBGAMES’09, pp. 17-26, Oct. 2009.
[7] L. D. Briceño, H. J. Siegel, A. A. Maciejewski, Y. Hong, B. Lock, M. N. Teli, F.
Wedyan, C. Panaccione, C. Klumph, K. Willman, and C. Zhang, “Robust Resource Allocation in a Massive Multiplayer Online Gaming Environment,” in
29
Proc. ACM 4th International Conference on Foundations of Digital Games, FDG’09, pp. 232-239, 2009.
[8] M. Marzolla, S. Ferretti, and G. D'Angelo, “Dynamic Resource Provisioning for Cloud-based Gaming Infrastructures,” in ACM Computers in Entertainment - Theoretical and Practical Computer Applications in Entertainment, CIE’12, vol.
10, no. 3, pp. 1-20, Dec. 2012.
[9] V. Nae, A. Iosup, S. Podlipnig, R. Prodan, D. Epema, and T. Fahringer, “Efficient Management of Data Center Resources for Massively Multiplayer Online Games,”
in Proc. IEEE International Conference on High Performance Computing, Networking, Storage and Analysis, SC’08, pp. 1-12, Nov. 2008.
[10] V. Nae, A. Iosup, and R. Prodan, “Dynamic Resource Provisioning in Massively Multiplayer Online Games, ” IEEE Transactions on Parallel and Distributed Systems, vol. 22, no. 3, pp. 380-395, March 2011.
[11] F. Glinka, A. Ploβ, J. Müller-lden, and S. Gorlatch, “RTF: A Real-Time Framework for Developing Scalable Multiplayer Online Games,” in Proc. ACM 6th SIGCOMM Workshop on Network and System Support for Games, NetGames’07, pp. 81-86, Setp. 2007.
[12] “OnLive,” [Online]. Available: http://www.onlive.com/.
[13] “CloudSim,” [Online]. Available: http://www.cloudbus.org/cloudsim/.
[14] “Artificial Neural Network,” [Online]. Available:
http://en.wikipedia.org/wiki/Artificial_neural_network/.
[15] M. Suznjevic, I. Stupar, and M. Matijasevic, “MMORPG Player Behavior Model Based on Player Action Categories,” in Proc. IEEE 10th Annual Workshop on Network and Systems Support for Games, NetGames’11, pp. 1-6, Oct. 2011.
[16] “MATLAB,” [Online]. Available: http://www.mathworks.com/products/matlab/.
30
[17] R. Prodan and V. Nae, “Prediction-based Real-time Resource Provisioning for Massively Multiplayer Online Games,” Journal of Future Generation Computer Systems, vol. 25, no. 7, pp. 785-793, July 2009.
[18] Y. Lee and K. Chen, “Is server consolidation beneficial to MMORPG? a case study of World of Warcraft,” in Proc. IEEE 3rd International Conference on Cloud Computing, CLOUD’10, pp. 435-442, July 2010.
[19] M. Mao and M. Humphrey, “A Performance Study on the VM Startup Time in the Cloud,” in Proc. IEEE 5th International Conference on Cloud Computing, CLOUD’12, pp. 423-430, June 2012.
[20] D. T. Ahmed and S. Shirmohammadi, “A Dynamic Area of Interest Management and Collaboration Model for P2P,” in Proc. IEEE/ACM 12th International Symposium on Distributed Simulation and Real-Time Applications, DS-RT’08, pp.
27-34, Oct. 2008.
[21] “MMOGs market capitalization,” [Online]. Available:
http://www.thealistdaily.com/news/global-mmo-games-spending-over-12-billion-r eport/.
[22] “Combat Log,” [Online]. Available: http://www.wowwiki.com/Combat_Log/.