Cloud gaming and simulation in Distributed Systems. GingFung Matthew Yeung. BSc Computer Science 2014/15

Transcription

1 School of Computing FACULTY OF ENGINEERING Cloud gaming and simulation in Distributed Systems GingFung Matthew Yeung BSc Computer Science 2014/15

2 The candidate confirms that the following have been submitted: Items Format Recipient(s) and Date Deliverables 1 Report SSO (12/05/15) Software Code Software codes or URL SSO, Supervisors (12/05/15) Deliverable 2 User manuals SSO (12/05/15) Type of Project: Exploratory The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) GingFung Matthew Yeung <2015> The University of Leeds and <GING FUNG MATTHEW YEUNG> ii

3 Summary A game engine is the core of a game, which generally contains major game components. Game engine can be computationally intensive and must operate with high frequency and low latency. User with limited hardware specification will not achieve the best gaming experience; therefore it will always be limited by the hardware available for the game computations, my aim of this project is trying to increase the hardware and resources available. This project will conduct a detail summary of why and how to distribute a game engine across a distributed system and whether it is feasible. Discussing the advantages of distributing a game engine and the disadvantages. Finally, to test the theory, in the final section will detail the evaluation done on my game simulation and give conclusion on its feasibility. iii

4 Acknowledgements I would like to thank the following people: My supervisors, Jie Xu, David Webster, Peter Garraghan for their supports, feedback, they gave me tremendous help along the way. My assessor Mark dekamps for his feedback on my project that helps me gains a deeper understanding of what I should clarified for my project. Those who gave me support and keep me going; my friends and family. iv

5 Glossary of Terms Abbreviation Term Definition CPU Central Processing unit The brain of a machine, contains processors and control unit. CPU perform most of the computation and instructions of a computer program.[21] GPU Graphics Processing unit Typically use for rendering, computing graphics computation and image processing. [22] MMOG Massively Multiplayer Online Game A type of game that can support a very large numbers of players simultaneously and usually involve playing through the internet. [1] FPS First Person Shooting A type of game that based on first person perspective and mostly played around guns. [1] VM Virtual Machine A software implementation of what you can see and do on a physical machine such as run programs etc. Each VM contain an amount of virtual CPU and memory usage. [23] AI Artificial Intelligence It is a computer programs that mimic human thinking and acting. [24] v

6 Table of Contents Summary.. ii Acknowledgements iii Glossary of Terms.iv Table of Contents....v 1. Introduction Project Aim Project Objectives Proposed Solution Deliverables Initial Schedule Background Introduction of Cloud Computing Introduction of Cloud Gaming Distributed Systems Cloud Computing and Distributed Systems Project Problems Related works Proposed Models and methodology Abstract System model Experiment model Methodologies Experiment Non-Distributed Distributed Summary Evaluation Project Objectives Project Requirements Project Schedule Conclusion Further Work Reference..54 Appendix A External Sources Appendix C User Manual Appendix B Ethical Issues Appendix D Personal Reflection vi

7 Chapter 1 Introduction Why is it that when running a game on your local physical machine, the CPU usage and memory usage takes up a large proportion of your machine? Why is it that sometimes the game is too advanced, the user local machine hardware component is unable to support the game? Typically, playing video games require high utilizations of hardware resources on a machine and that is what causes the game look stutter sometimes. In a MMOGs game, network latency can also cause a game to slow down and looks lag. There are so many factors that can vary gaming experience on user physical machine. One thing for sure is that running a game can be computationally, memory usage intensive, and must operate with high frequency and low latency as stated in [9]. There must be a lot of calculations causing users machine to run into resource bottleneck or bad gaming experience. This is because in the core of a game, an engine is running game engine. But what is a Game Engine? In the book Game Engine Architecture [1], the author gave a complete review of the core components of a typical game engine and is essentially the core of a video game as shown below; Fig.1.15 Game Engine Architecture: Runtime game engine architecture 1

8 There are plenty of components in the engine shown above however the major components are: Graphics engine Physics engine AI engine Currently in modern industry, most gamers focus on the graphics and physics aspect of a game, seeking for perfect and realism graphics; therefore as stated in [17,18], in a Massive Multiplayer Online Game, the game server which run the game engine used up most of the computation power to support major graphics rendering and physics calculation; hence it gives insufficient computing power to support computational demands of thousands of even moderately sophisticated, concurrently running Ais. [6] While graphics and physics component are important to a game, to make the game more enjoyable, smarter Ais are also desirable to be present in better game design. In other games, one such as Dwarf Fortress [20], a single player construction game that runs in single threaded; large numbers of entity are present in the game, resource bottleneck occurs often, frame rate also drops intensively as time goes on, and because of the game keep tracks of almost every entity, including running AI calculation, this will causing memory, CPU usage to build up. This can results to a massive drop in frames rate, because the game loop has to wait till all computation finish for each frame, then renders it, this can makes the game looks lag ; thus gaming experience is not enjoyable. This proves that AI calculation is indeed as important and largely complex as graphics and physics calculation. Therefore game engine and the game design architecture is an important blue print of a successful game. 1.1 Project aim With more and more computation expensive games, accepting large number of players, gamers local machines hardware specification are required to update frequently, which costs gamers money and time to do so. Therefore as stated before, this project aim is to increase the hardware resources available for game computations. Currently there are three types of distributed game architectures that can take the pressure away from gamers local machine: Type 1 Client server architecture, such as Quake game server. It is a 3D FPS game involving a number of players or can play in a single player mode. The architecture behaves as the server runs the game loop; clients and 2

9 server both have game engine. Multiple users connect to server and send in control input, then receive results via the Internet and render the scene on users one physical machine as described in [28]. This means that if the client machine hardware components are out-dated, gaming experience is not ideal, plus this is very latency sensitive. Type 2 Cloud Gaming, it is a new approach that emerges recently to help users with limited hardware components on their machine by taking advantages of Cloud Computing paradigm. This will be explained in details in the following chapter. Type 3 This is as described in [31] by Jiaqiang, et al, taking an approach of peer-to-peer model, distributed game computation to clients from the server; however exposing the risk of allowing bad gamers to hack, due to codes are available in the client. These three approaches are good way to host a game and help ease the pressure on clients machines. However these three approaches have been explored and optimized for good; there is another possibility, in which this project is going to explore and identify whether it is feasible to do so. The idea is that, the game engine of a video game is on user s local machine. Next, user can take advantages of his additional local physical machines, not limited to only one machine if other machines are available; to make up or improves gaming experience by distributing the core components of a game engine to other distributed nodes, to calculate intensive computation and do different tasks, forming a distributed system. For example: A typical PlayStation 4 from Sony has 8 CPU [29], with this approach additional machine that has 4 CPU can contribute and therefore as a whole distributed system, 12 CPU is available for the game computations. With extra resources, computations can be done faster. Gamer will have an option of Boosting, limiting the machines running into resources bottleneck because of hardware limitation. However there is a possibility that communication between machines involve overheads. Further more, connection of the machine should be done in a network which as a distributed system, fallacies cannot be easily avoided as described in [7]. Therefore, the aim of this project is to explore, identify the feasibility of distributing the core game engine components, across a distributed system; also to evaluate the effect on performance and find the optimal threshold after it has been distributed. 3

10 The performance could be measured by the computation frame rate (game loop computation) and monitoring the CPU usage as well as memory. The time to get all processes done and render the scene is the main issue of this project. The key challenge of wanting to use a distributed system approach but maintaining low latency is hard. This is a well-known fallacy in a distributed system. This project will also investigate the effect on latency occurring. 1.2 Project Objectives The objectives of this project are: 1. Research on previous work, and the idea of using distributed system for solving hardware limitation of game computations. 2. Experiments the feasibility of the distributed system approach of gaming, and identify the pros and cons of this approach. 3. To do the experiments, the following procedures are carried out: Designing a game simulation for experiment a. In single threaded, showing that resources bottleneck do occur on one physical machine, the relationship between CPU usages and frame rate. Identify which game engine component uses the most resources. b. In a distribution model, ideally to show that being able to distribute part of a game engine can improve game performance as a whole system. For example: frame rate does not drop as intensively, CPU usage does not increase as intensively. 4. Future work in relation to this project aim in a more scalable model, suggestion of using cloud-computing paradigm as part of a distributed system. The model will be introduce and explain in the next chapter. Finally, this project will gather my experiment results; measure whether improvements are achieved after distributing an engine component across another physical machine as distributed nodes. 1.3 Proposed Solution As described in [6], currently most types of game in order to support large and surreal 3D graphics, accurate physics calculation for large number of entities, AI computations are suppressed. Also, in games that have a large entities with a large world, such as Dwarf fortress as mentioned in the introduction, these type of games will include lots of AI calculation; described by Janusz Grzyb, in [10] it is common that AI computation gets larger when world map get bigger, this is because of algorithms such as path 4

11 finding, this will involve to search for optimum paths for a large number of entities lead to the build up of large AI computations. Another article taking a FPS game F.E.A.R. [30], it described that most commonly seen and implemented AI computation are A* path finding algorithm and Finite State Machines, it is used a lot in video games in general, these algorithms can consume a low of CPU usages. Therefore, according to these two articles, I am assuming that AI computation can get heavy for games; although other components computations can be expensive, in this project I am going to experiment and note down the CPU usage on each component. Finally distributing the heaviest computation component to another physical machine, thus identifying distribution of game engine is whether feasible or not. 1.4 Deliverables The deliverables of this project include: A report, which contains my evaluation and background information. Software Code/ URL on github of my implementation of the experiment game model. User Manual for the software. 1.5 Initial Schedule Figure 1.1 Initial Schedules. 5

12 Figure 1.2 Initial Gantt chart 6

13 Chapter 2 Background This chapter gives the background information of this project and the definitions of the following: Cloud Computing Traditional approach of Cloud Gaming Distributed System Cloud Computing and Distributed System Project problems 2.1 Introduction of Cloud Computing Cloud Computing, where resources, services and applications at the data centers are shared, delivered over the Internet definition in [2]. According to one of the biggest cloud service provider Amazon Web Service [3], the term Cloud Computing refers to the on-demand delivery of IT resource and applications via the Internet with pay-asyou-go pricing. The on-demand resources Quality of Service should be maintained and agreed upon usage of the cloud via Service Level Agreement. The resource manage should assign and guarantee the resources at all time as described in [14]. In [2], its definition of Cloud Computing also include resources sharing, therefore as resources are provided by cloud providers from data centers, this include data storage, software applications, infrastructure, system platform; this gives major benefits of using cloud computing and is also defined as: Avoid need to install software application and be able to access software applications Software as a Service. Virtualization; virtual software tools, virtual platform for cloud users to create and build cloud application Platform as a Service. Provided fundamental resources such as CPU, storage to run software etc. Infrastructure as a Service. The three services above gives great scalability to the cloud, essentially the cloud could become an additional large computer to process, run or build other software applications. As long as you have a machine that can connect to the Internet. 7

14 2.2 Introduction of Cloud Gaming The current state-of-the-art, Cloud Gaming is described as where games are provided via the cloud from the data center; this is a similar approach to video streaming as stated in [4]. This cloud gaming model required users to access the game through the internet using a thin client application installed on local machine similar to Quake server as describe in [28]; however the game engine itself is not included on the user machine, the game engine is located in the data center. The user then provides input control, through thin client similar to Quake, inputs get delivered to the data center; the server then does the calculation while running the game loop and renders the scene in the data center. Finally the video data is sent via the Internet, back to the client as video streaming. This is described in detail in the article [4]. The main benefits of this model are: Avoid upgrading their computers for latest games Games can be played on different platforms via the client Play more games due to hardware/software incompatibility From these three statements, it is clear that user can rely on the data center high computation power and graphics card to render and compute the game scenes calculation; this has greatly reduced the need to constantly upgrade user s local physical machine. However with this approach, it is very latency sensitive due to the fact that it is streaming video, when a packet is lost or missed, video quality can be greatly reduced. Also due to the fact that user local machines do not have the game engine at all, when missed a packet, the game can appear as stopped, equal to a frame has dropped. Currently there are quite a few companies that support this type of cloud gaming system such as: OnLive StreamMyGame GaiKai (Sony) NVIDIA GRID However this does not solve my project objective as distributing the game engine as the game engine is not located in the user local machine at all; the down side of this model is if the data center does not have the game engine of that particular game then you can not play, and you have to connect to the internet for this model, the system this project targets will be discussed in chapter three. 8

15 2.3 Distributed System Defintion by Coulouris, George F., Jean Dollimore, and Tim Kindberg in [25], in a distributed system, typically it is where a number of computers forming a network that allow communicate and coordinate their work concurrently within the network by sending messages within. This is shown on below figure. Service Models for Distributed Systems: computer network According to this definition, the Internet, where it is a massive network of computers, can be described as a distributed system as it can allow communication by passing messages and capable to collaborate work on end-to-end nodes. In the book [26], distributed system is described and defined that it has characteristics such as: Geographically distributed in [26], the banking network with ATM communicate to a server that is geographically placed. Resource sharing in both [25,26], states that resources sharing is a trivial characteristic, for example when one machine needs additional storage can ask for another availability. 9

16 Scalability in [27], it refers to the number of users, while remaining large scale, the ability to operate efficiently and remaining good responsiveness. For example: one machine fails in the network does not disrupt and ruin the operation. Distributed System design can be used in games that offer a very large scalability. Typically for games that involved in a large number of nodes connect to the game server. This is best explained and demonstrated using the type of game -- MMOGs; In [1], MMOGs is described as where large numbers of players connect to the geographically distributed game server, the game engine is inside both client s machine and server but game states calculations are inside the server as it keep tracks of the number of players, players game information, their positions etc. In article [25], another definition of distributed system in game is Users are dynamically allocated a particular server based on current usage patterns and also the network delays to the server. A practical example of distributed system approach in games; in article [17], it identify that AI computation in the game server can be expensive, therefore Douceur et al. (2007) experiment with offloading the AI computation by splitting high frequency but not as intensive computation in the server and distributing lower frequency needed but high intensive computation to the client. Their model focuses on just distributing the AI computations to client on one machine; whereas this project idea focus on distributing the game engine components to any machines that the user owns, thereby taking advantage of users owned machines extra resources. 2.4 Cloud Computing and Distributed System According to the definition of distributed system and cloud computing, both definitions consist of resource sharing, therefore cloud computing can be considered as a distributed system due to its characteristics of resources sharing on demand. Resource sharing is a big characteristic in cloud computing and distributed system; in cloud computing definition, where resources are request on demand then the underlying hypervisors can allocate more resources to the VM. Whereas in physical machines distributed system approach, the resources are always there and pre-allocated for the machines. Cloud Computing can allow VM to coordinate and communicate to do work or process concurrently within the cloud; this is essentially the definition of the distributed system where a group of machines forming a network, and concurrently working; Therefore in this project I will consider that cloud computing is a type of distributed system. 10

17 However this project aim is to focus on, distributed game engine component over a distributed nodes, using a cloud-computing paradigm for distributing a game engine is not necessary needed but the aim is to explore the feasibility of distributing game engine in a distributed system, and the Cloud is just part of the exploration. 2.5 Project Problems Looking back at the traditional Cloud Gaming approach, distributed AI computation approach and Quake centralised server approach, it does not solve my project aim of distributing the game engine across a distributed system or distributed nodes where a user can take advantages of extra hardware resources. In the book Game Engine Architecture [1], its description of game engine is at the core of the game, game engine is responsible to run iterations of the game engine loop. This game loop contains the major game engine components calculation and computation plus the other small subsystem of a game engine, and typically all calculation and simulation should be at the rate of 60 frames per second (16.67ms) or 30 frames per second (33.3ms) [1] depending on the type of the game, in this project we will simply call this frame rate. After each loop finish, the scene (one frame) will get virtualised, rendered by graphics component of the game engine and displayed on user machine. In the traditional Cloud Gaming System, the game engine and game loop is centralised at the data center similar to the Quake server approach, but user does not have the game engine and then the game is rendered at the data center on one machine [4]. This one machine contains a finite number of CPU and Memory, thus there is a limit of the amount of work in one machine can do. Cloud Gaming user takes advantage of this one machine and thus play the game via the Internet and streamed the rendered video on client s machine. In more traditional approach of video gaming, where game is installed in players physical machine locally, the game engine itself, the computation, rendering are all running inside the player s physical machine as described in [6]. Thus the local machine is doing all the work, which requires intensive CPU usage and Memory usage. This is also the approach of the Quake Centralised server model as the game loop is running on server, but client run the game engine to render the scene. The above-mentioned approaches do not solve the intended project aim. The challenge of this project is to distribute the game engine component, inside a data center. Thus users can take advantages of the data center resources, multiple physical machines such as CPU and additional memory while maintaining a good gaming experience. 11

18 A data center can have multiple physical machines; these physical machines can be a distributed system by forming a network thus sharing resources for game engine computation is available; or in another medium by hosting a cloud environment, which allows virtualization to take place if a cloud system is available. Thus resources can be shared on demand such as CPU, Memory and data storage. Virtualization can allow VM to be spawned and handled different processes whenever needed as described in [14]. The benefits of using virtualisation, is that the ability of scaling the available resources, for one Virtual Machine; Typically one physical machine with multiple CPUs run the whole game engine; with virtualization, one powerful physical machine can host multiple VMs, therefore each VM can host a component with enough resources. Global Scheduler in the cloud should maintain and manage the workload of all VM. This project is to explore the feasibility of distribute the component across a distributed system with distributed nodes; cloud computing is in fact a type of distributed system and therefore can be a distributed node; as described above, resources and application can be shared and processed in a cloud environment. However with this project, the experiment will be using the physical machines approach in distributed system in Eniac laboratory, identify if game engine component distribution across a network is feasible, then next stage, which is further work, could be distribute on to the cloud as an exploration. The main variables to be consider when evaluating the experiment are: Latency issues Most of the online game, especially real time critical gaming such as FPS are time sensitive, this will be one of the area to be evaluate in the evaluation section. Resources issues To evaluate the resources bottleneck and the overhead of distributing and communicating. 2.6 Related Work As mention in chapter one, there are three types of gaming system that can solve the resources bottleneck issues. In this section, related work on distributing the game engine, apart from the three types of gaming system discussed in chapter one will be discussed here. In Enhancing Game-Server AI with Distributed Client Computation, Douceur et al, their aim was to prohibit the expensive computation on a central server (one machine) in the context of online RPG. Their method was to split the AI into two, one that is needed by the server in a high frequency but simple computation stays in the server; another that is heavy computation but not frequently needed by the server will get distribute to the client machine. However they states that the approach is not without 12

19 sacrificing the security of the game and communication delay could be add to code that normally executes inside the game server. Finally their finding is that their technique successfully reduces an amount of computation in the server and even the latencies are more than one second; they also suggest that when threshold of one second is reached on network latency, the better choice would be to do the computations inside the server. In Is it Practical to Offload AI over the Network, Bai et al, their work focus on distributed the AI to all client machines in a P2P network. They states that the drawback of their method of offloading AI to clients will expose their AI code to all client machines, which can allow hackers to modify the game. Also their finding was that after a threshold of 275ms latency, their implementation starts to perform worse. Both of their method consists of distributing the game engine to an unknown client via P2P network or simply distributing to an unknown client, to harness their computation power but sacrifice the security of the game. Whereas this project focuses on distributing the game engine inside a data center or a cloud therefore part of the game engine is not expose to any players except the one who is running the game engine. For example in a MMOG, server running the game engine that do all world computation on one machine, players run a client that receive the game state and render all their local machines. With our propose model, the game server can distribute part of the game engine within a data center that is relatively closed to the machine that run game loop, saving resources on the server thus resolving resources bottleneck that causes the game server to break down. 13

20 Chapter 3 Proposed Models and Methodology In this chapter, the following models will be introduced and explained: Abstract system model this will explain how cloud computing can be applied to a distributed system approach on this research however I did not implement the abstract system model during this project, this is related to further work in chapter 5 on this project. Experiment distributed model this is the approach of where this project will experiment on. This will be evaluated whether distributing game engine is feasible and the results will be discussed in chapter Abstract System Model This is a theoretical, further work, abstract system model and taking advantages of Cloud Computing the aims are: User could sit and play on his local machine, while not having enough resources; user could use the extra resources available in the cloud provider data center. Game engine components can be able to distribute to those extra resources VMs or distributed nodes. VM can execute the computations required by each game engine component. Quality of Services needed to be maintained and agreed upon first usage. Global Scheduler or Hypervisor to manage the workload of all VMs. At first usage, before distributing the game (figure 3.1.1), user should establish the QoS with the service provider via the Internet. The Cloud service provider should then have the idea of the amount of resources they should guarantee and maintain when providing VM for client usage. Next, User runs the game loop on his own local machine only, while not having enough extra resources, user can distributed the game engine components onto the cloud, which the data center host. The Cloud contains VMs that are responsible for each component computation as seen below on the figure However since the cloud resources are on demand basis, with extra resources, the VM that host the component can distribute tasks to the extra VM for quicker computation. 14

21 Finally since the user local machine is running the game loop, the loop will be set to 60FPS, so each loop is running in 16ms, ideally getting the results from the network should be inside this time. Figure This figure demonstrate at first usage, where user local machine still containing the component and need to establish the QoS via the SLA with the cloud service provider s data center. 15

22 Figure This figure demonstrate the components being distributed to the VM, and with extra VM, tasks can be execute faster. 16

23 Advantages of this abstract system model, user can rent resources available on the cloud system, as part of a distributed system, to calculate intensive computation required by the game engine. Assumptions for this abstraction model: The service provider will establish the SLA. The Data Center and the VM will not fail. The network between user and data center will not fail. The game loop should constantly be running as fast as possible around 60FPS. 3.2 Experiment Model Below described an experiment model that this project used to identify the feasibility of distributing game engine component across distributed nodes. To identify the benefit of distributed component compare to running the game on machine only, the first experiment will run the game on one physical machine; it is implemented single threaded, also the application will be set to run on one CPU only with taskset Unix command. This experiment aim is to find out there is limitation, and it is in one machine on one CPU while using my single threaded game model, discovering which components uses the most time for one frame, also identifying the CPU usage and frame rate differences on various game settings. The reason is that the first experiment results will be used as baseline, comparing to the distribution game engine model, seeing if improvements are made. After discovering which game engine component uses a lot of resources compare to the others, then the aim is to distribute this component to available machines. Therefore In the second experiment, running the game on two physical machines and three physical machines will be explored; one machine starting the game loop consisting other components that not as intensive as the one discovered in the first experiment, and the others will run the distributed component computations. The implementation is that, the game loop will try to run as fast as it can to optimize gaming experience, therefore the time to finish each loop will be set to 60FPS (16ms) where most type of video game has been set to run in. In the game design, when the client machine, responsible for the distributed component computation, and connect to the game loop machine, server (game loop machine) will spawn a thread for each client handling the communication, the purpose 17

24 of the thread is to handle the communication without the game loop block and wait for the communication to finish. This is shown as below figure and figure Figure A blocking model of the threads, for example thread two finishes way before thread 1, but have to wait due to thread 1 hasn t finish yet. And the game loop (server thread) will have to wait for both threads to finish before finishing the loop (one frame). Figure A non-blocking model of the threads, this is the model I am implementing. Advantages of this model as explained above, game loop continue to execute without waiting for the threads finish, so as the threads, client can continue to execute communication and computation without waiting for one to finish to achieve faster execution. If waiting the result to get back every loop, game can appear slow and will not achieve the optimum 16ms loop time. (Results not get back to the server between 16ms.) Furthermore if it has to wait for the result to come back when latency occurs in the network or data is lost in transition, game can appear stop or the scene has suddenly jumped if graphics component data is lost. (Results do not return at all.) 18

25 The data transition method will be using a socket stream structure. The aim of this experiment is to find that after distributing the computations, the CPU usage does indeed dropped on the machine which run the loop, as well as frame rate will not get slowed down as quickly. These can indicate that distributing components does save an amount of resources and game loop is executing as fast as possible. However as described in figure 3.2.2, if game loop is running at the optimum rate, the data does not get back in time for each loop, the game quality will also decrease. Therefore choosing the right component to distribute is vital. As per my research indicates and as stated by Douceur, et al in [17], AI is the most latency resilient component in the game engine, due to the fact that some large calculation results for AI is not as frequently needed by the game state. It can go up to 1 second. While physics and graphics component, to make the game as virtually real as possible, the components are required to run as quick and as accurate as possible as described in the book Game Engine Architecture. Therefore in this project experiment model, experiment one, while trying to find out the limitation, and find out which component uses the most resources, the aim is to prove that AI can also consume a lot of resources as stated in chapter 2; thus distributing AI can be and is a good option for distributing game engine component, because it is more latency resilience for a video game whether it is multiplayer or single player. Although distributing AI is a good option, this project is to identify if components are feasible to be distributed, therefore physics and graphics can be a good option as well if results indicates that it is more feasible to do so. The complete methodologies of the experiment one and two will be explained in the next section. The Assumption in this model is: The Clients (distributed machines) will not fail. The data will not lost in between transition. 19

26 Figure 3.3 Experiment Model The above figure 3.3 shows the basic model of my simulation. However the game engine component will be explored is the Ai component as described above, this project experiment will use two machines for Ai computations. In below section 3.3 will have the project experiment detailed implementation of the simulation. 20

27 3.3 Methodologies Although there is free open source game engine on the Internet such as Quake, Quake-II, Unreal, these are the game engines that allow developers to get a deeper understanding of complicated game architecture; writing a implementation is a good way of learning and practicing game developing also can help building a stronger foundation of programming techniques. In the game-simulation implementation, the simulation will be similar to Pacman/Bomber man, a type of strategic, 2.5D maze game. This is due to the fact that, graphics rendering, physics calculation and AI calculation will go up as the game entities increase (graphics and physics collision detection) and the map-size increases (physics, AI path finding). Allowing the experiment to identify that indeed resources bottleneck will occur. The experiments will be conducted in the Eniac Laboratory in the University of Leeds, where the machines will be having Intel i (4 CPU) and 16GB Memory. In order to make the CPU usage to go 100%, all four CPU must be doing intensive work. However my game implementation is a single threaded game. Therefore, setting the game to only run in One CPU, so that when monitoring the CPU usage, only need to monitor one CPU; also reaching 100% on one CPU is much faster. In the game model, graphics component will draw the maze including the walls, the cheese, and the entities. Physics component will handle the collision detection between each entity and the world objects. Next, two entities will be present in the simulation with AI implemented Cat and Mouse. Each entity will run its own AI calculation. The AI calculation consists of finite states and a method that simulate heavy, computationally expensive calculation on A* path finding as stated by Leigh et al in [32]. The simulated method will be calculating prime numbers and will be increased and scaled up quickly as the map size gets bigger as I have set it to find all prime numbers between MapSize*MapSize. Each finite state will be show in figures below (figure ) including the state flows diagram in figure (3.3.1). After the diagrams, the following paragraphs will be the details of the game objectives. 21

28 Figure This figure shows that in each animal, the finite states include Patrol, Tired and Hungry. And each animal will keep constantly checking its status whether it is tired or hungry or stay in patrol state in each Game Loop. Patrol State is the default normal state. 22

29 Figure This figure shows the basic actions inside the Patrol state, while it is not in another state, this state will get called and execute the methods as shown above. The detail implementation will be inside my github repository in the AI directory. 23

30 Figure Basic actions inside the Hungry state. 24

31 Figure Basic methods in Tired State. 25

32 The aim of the cat is to catch any mouse and will be represented by a white cube. The aim of the mouse is to get some cheese and will be represented by a turquoise cube. The animals cannot see anything that is to make the collision detection happen frequently. There will be a three-dimension tile map that contains wall, cheese and the animals. This is shown as below in figure Figure D game simulation. 20x20 Map Size. In the software implementation, Model-View-Controller structure is implemented; which the view represents the graphics component; the model contains physics calculation, game objects, entities and it is also responsible for handling the client; finally the controller is responsible for the viewing controls. This is as shown in below figure Figure The MVC model of this application, game model is the class that handles all the objects and run the game loop. 26

33 Therefore in order to make the simulation 60FPS, the simulation is set to run in 16ms to render the scene in the view class. The collision detection in the model class will keep track of each object test against each entity. In the simulation, each entity does not need to communicate with each other; within each animal, state is a private variable inside of each animal; inside each state, animal will constantly being checked on certain variables if required to change state. Therefore when distributing the AI, distributing the finite state machine calculation to the other machines are carried out; the client will calculate what state the animal it should be in, and send the result back to the server, update that animal to a different state; the server will run graphics, physics and jobs it should be doing when in certain AI states such as animal.patrol() if the animal is being told to be in patrol state. The method of distributing the AI states computations will be using client and server architecture via sockets as described before; the server is the machine that is running the game loop and handling the connection to a client, which is machine that host the AI component and do the calculations. When the server starts, entities will not be moving until server receives responds from clients. The architecture is shown as below figure Figure This figure shows that the server (machine that run the game loop) contains N animals, while two machines have connected to the server; the animals are equally distributed to the clients. Since between each animal, there is no communication, the overheads between clients are none. 27

34 In the model, as described in 3.3, since each client is being handled with a separate thread, if one client is slow or network is slow, the animals being handled on that client has a potential of delay in updating the states; however it does not affect the animals being handled by the other client. Next, the size of the map can be specified, the map will be randomly generated along with the walls and the animals; the number of animals also can be specified in one of the header file gamemodel.h. However it is not evenly generated for the number of cats and mice, as the cats and mice are randomly generated according to the size of the animals. The complete flow of server and client are shown below in figure 3.3.8: 28

35 Chapter 4 Experiment This chapter is to analysis the data gets from the experiments; first looking at the nondistributed model, identify the heavy computation components and finding the limit on one CPU with different game setting. Next looking at the distributed models, with onemachine then two machines, identify if distributing AI component can save resources on the machine that run the game loop, and look at if improvements are made in the distributed model. The data are recorded down as a text file, writing down the frame per second, update time, time to finish AI, graphics and physics calculations, each experiment will run for one minute to get a number of data to calculate the average. With the Distributed Model, the data recorded will involve an additional the communication time (round trip time) between each client and the server. This communication time include (1) the time taken for server sends game state data to client, (2) wait for client to finish calculation and (3) received a respond from the client. Since handling the client is in a separate thread, the communication time for each client will be different, the time will be compare to the frame per second; if the communication time is longer than the frame rate, that means it has missed a frame for the entity to be in the appropriate state. Although as described in chapter 3, section 3, AI can withstand latency up to 1 second, therefore if the communication time is larger than 1 second and is slower than the frame rate, then it is not feasible to distribute the component. However it does depends on the type of game that is being played, if it is a fast paced game such as FPS, then it is obvious that 1 second is way too slow for the results to get back; if it is a slow paced game such as chess game, strategy game or turn based RPG game, then 1 second or more maybe acceptable depends on the players. However this project aim to make the communication time within the frame rate or inside the 1-second mark. 4.1 Non-Distributed In this section, the discussion will be on how the CPU varies and the frame rate differs with different game setting on one machine and on one CPU single threaded. In the experiment with a centralised game model, a number of experiments with different settings were carried out; the control variable is the Map Size, whereas the independent variable is the number of animals. For example: 20x20 Map Size, 40x40 Map Size, and on each map size, steadily increase animals size while map size stays constant. Below will show a series of figures showing the CPU usage, frame rates, and time taken ratio of each component in one loop. Recall in chapter 3, AI component 29

36 computation will not be as intensive due to the fact that the smaller the map size, the AI algorithms of path finding can do less work; this will be shown in below experiment result. Next, while increasing the number of animal in a small map, the physic component calculation should add up, as collision will happen more due to a smaller map with more animals bumping into each other. Therefore with this setting I should expect to see the time it takes to finish physics calculation in one frame should take up the most time when number of animals are high. Also expect to see, to reach 100% CPU usage on one CPU, the maximum number of animals allowed in a small map should be larger than a large map size; this is shown as below on figure and figure the maximum number of animals varies by Then, gradually as map size gets bigger, the AI computation ratio in one frame should be getting more intensive and taking longer time to finish, as path finding computation should increases with map size (my simulated prime numbers finding algorithm scale up with map size). Also as described in chapter 2, since AI computation gets heavy and takes up most of the resources, the CPU usage on one CPU should increases along with the map size, therefore to reach 100% CPU usage should be reached quicker than the previous smaller map setting as AI is doing more work with each animal. Map Size Number of Animals 20 x x x x x x x x x x Table the number of animal it takes to reach 100% CPU usage on One CPU. 30

37 Figure this figure show that on a 20x20 Map Size, as the number of animals increases, with less intensive AI computation setting, the maximum number of animals to let one CPU to reach 100% can be up to Figure this figure show that with slightly larger map 40x40, meaning slightly more intensive AI computation than previous setting, the maximum number of animals to let one CPU to reach 100% decreases to 7000 entities. 31

38 Figure this figure show that with 80x80 map size, intensive AI computation is taking place, therefore maximum number of animals to let one CPU to reach nearly 100% to 300. With the above figures 4.1.1, and figure 4.1.3, they are showing that resources bottleneck do indeed happen on One CPU. Also as the map size increases, the maximum number of animals decreases, however this does not show which components uses the most CPU and the frame rate. Also with the results shown above, since reaching 100% on one CPU is possible when running a game, possibility of four CPUs running into resources bottleneck can also happen when too many entities are present in a game. In Akliz.net, a high performance hosting game server website, it states that 100% CPU can often happen when too many entities are present in a construction game Minecraft [33]. Therefore with the above figures, the experiments of one machine have demonstrated that resources bottleneck is an issue in day-to-day gaming; and it indeed happens in this project experiment on one CPU. Game quality can be represent by frame rate as well as CPU usage, this is because Frame rate show how many frames are being rendered in one second, and if frame rate is quick, then the game scenes will look smooth. If frame rate is slow, the game scenes will look lagged and jumped. 32

39 Before showing which components take the longest time to finish its computation in one game loop, below figure show the corresponding frame rate with the 20x20 Map Size when increasing the number of animals. Figure corresponding frame rate with 20x20 map size experiments described above. It is dropping as the number of animal increases. With the above figure 4.1.4, this correspond to the figure 4.1.1, as the number of animal increases, CPU usage increases, and FPS decreases nearly to zero; practically look like the game has stopped, this show that the gaming quality decreases when CPU usage is high. Also note that I have set the game to run in 60FPS, but even in a low intensive setting, the starting FPS is at 45. Next, below figure show the corresponding frame rate to the experiment on figure 4.1.2, frame rate of 40x40 map size. 33

40 Figure frame rate of 40x40 Map Size and related to figure The figure once again shows that the frame rate decreases along with the number of bots, same as figure shows; both settings 20x20 map size and 40x40, shows that when number of bots increases, CPU usage on One CPU increases, hence the frame rate drops and gaming quality decreases. However, with the above figures they do not show which component uses the most resources hence the times of each component to do its calculation in one game loop are recorded. E.g. (Time taken for Ai) divided by (Total time taken in one loop). This can calculate how much ratio each component is using. Below figures will show the ratio by each component on time taken to finish calculation in one game loop on each game setting. 34