Proc. of Int. Conf. on Recent Trends in Information, Telecommunication and Computing, ITC
Development and Simulation of Pacman Game using Multi-Client Architecture via Player/Stage Tool Mitali Sodhi1 and Madhav Rao2 12
International Institute of Information Technology, Bangalore, India 1 Email: Mitali.sodhi@iiitb.org 2 Email: mr@iiitb.ac.in
Abstract— A rapid progress is seen in the field of robotics both in educational and industrial automation sectors. The Robotics education in particular is gaining technological advances and providing more learning opportunities. In automotive sector, there is a necessity and demand to automate daily human activities by robot. With such an advancement and demand for robotics, the realization of a popular computer game will help students to learn and acquire skills in the field of robotics. The computer game such as Pacman offers challenges on both software and hardware fronts. In software, it provides challenges in developing algorithms for a robot to escape from the pool of attacking robots and to develop algorithms for multiple ghost robots to attack the Pacman. On the hardware front, it provides a challenge to integrate various systems to realize the game. This project aims to demonstrate the pacman game in real world as well as in simulation. For simulation purpose Player/Stage is used to develop single-client and multi-client architectures. The multi- client architecture in player/stage uses one global simulation proxy to which all the robot models are connected. This reduces the overhead to manage multiple robots proxy. The single-client architecture enables only two robot models to connect to the simulation proxy. Multi-client approach offers flexibility to add sensors to each port which will be used distinctly by the client attached to the respective robot. The robots are named as Pacman and Ghosts, which try to escape and attack respectively. Use of Network Camera has been done to detect the global positions of the robots and data is shared through inter-process communication. Index Terms— pacman; player/stage; multi-client; robotic- simulation;
I. INTRODUCTION The original Pacman is an arcade game developed by Namco and first released in Japan on May 22, 1980. Pacman was designed to have no finite ending. Pacman is an entertaining and a popular game in the history of the world.[1] The player controls Pacman through a maze, eating pacdots. When all pacdots are eaten, Pacman is taken to the next stage. The enemies in Pacman are known as “ghosts” or “monsters”. Despite the seemingly random nature of the enemies, their movements are strictly deterministic, which players use to their advantage [2][3]. Simulation of the robots before it is implemented in physical environment leads to analysis and insight on its physical behavior. It also saves from the irreparable damage to the hardware that could have been caused due to miscalculations. Anderson et al. (2007) [4] have described Player/stage as a simulation tool, which DOI: 02.ITC.2014.5.84 © Association of Computer Electronics and Electrical Engineers, 2014
provides robotic behavior close to physical environment. The Player/Stage provides accuracy, speed, and efficient demonstration making it suitable as a simulator for robotics environment. Two robotic environment models were implemented to complete experiments. One model involves using three models of iRobot, which is following multi-client architecture. The other one is using two models of iRobot, which is following single-client architecture. Multiple algorithms run at the back end to control the movement of the pacman and ghosts. These algorithms instruct the pacman or ghosts to take strategic movements in order to accomplish their goals of escaping and attacking each other. For physical implementation of the game, iRobots Create programmable robots were used. They are connected to a remote workstation using a Bluetooth model. The iRobots positions were detected using a network camera. The realization of the game involves strategic attack and escape algorithms, inter-process communication and position detection of robots via network camera using blob detection methods on the frames captured by camera. Network camera as a sensor was preferred to other sensors which provided relative positions of the robots. Five sets of experiments have been done by placing the robots in different positions to test the algorithm. In player/stage simulation model, the experiments were tested on two environments: one using a 6X6 cells (having 1 pacman and 2 ghosts) and the other with 3X4 cells (having 1 pacman and 1 ghost). The second environment was selected to confirm our experimental environment using physical robots. The network camera, which was mounted on the ceiling, was able to capture an area equivalent of 3X4 cells. So, a similar setup was created using the simulation to test the algorithm in simulation and physical environment. II. RELATED WORK This paper follows the work done in [5] by Madhav Rao. This paper followed the single-client architecture model. In this model, there is one pacman and one ghost. They both connect to a single port for the simulation to work. This model was implemented using simulation as well as physical implementation. A key algorithm, blob detection, socket programming and inter process communication for robot synchronization has been adopted to show the movement of robots in the physical environment. The basic architecture involves a shared camera based robot localization process. The individual Pacman and Ghosts processes are independent, yet needs positions of Ghosts and Pacman positions respectively to make their next move according to each other’s positions. The individual processes as shown in Figure 1 includes path planning, execution and obstacle avoidance. The boundary conditions of the map are considered in obstacle avoidance process. There have been other efforts also taken in the past via robotic simulation techniques. Faust J. et al. discuss about a robot simulation environment used in video games to show various methods of depicting the robots in any simulation-based environment [6].
Figure 1. Schematic showing the behavioral model of pacman and ghost processes in a pacman game
12
III. ATTACK AND ESCAPE ALGORITHMS There are two basic algorithms used in this project. The Ghost uses an algorithm to the attack Pacman. Pacman uses the escape algorithm to elude from the ghosts. [7] The pacman and ghosts require the positions of ach other in order to compute their next move to accomplish their goals of escaping and attacking. So, for this purpose, in simulation the positions for the pacman and ghosts are obtained from the position2d simulation proxy [8]. Position2d is the relative position of robots with respect to its initial position. While in case of physical implementation using actual iRobots, the blob detection method used on frames captured by network camera provides the global positions of the robots used in the game. The Ghost robot was identified by detecting red color, which is mounted on top of the iRobot. Similarly detecting yellow color, which is mounted on top of the iRobot, identified the Pacman position. For the attack and escape algorithms, the robots followed a path planning approach. Pacman tries to move in an opposite direction to ghost and maximize the distance between them. While ghost tries to move towards Pacman and minimize the distance between them. At every step, the robot checks whether they lie within the boundaries of the map. If they reach the boundaries and hit them, it will be treated as an obstacle and they will not be able to surpass it. So, they need to make a decision of the correct direction in which they have to move. On reaching the corners of the map, the robots apply their respective boundary conditions in order to determine the direction in which they have to turn. Pacman tries to move in opposite direction of Ghost and Ghost tries to move in the same direction of Pacman. The three major tasks for the robots are: • Pacman estimates an escape route based on Ghost’s location • Ghost estimates the shortest attack route by finding the Euclidean distance • Keep checking for boundary conditions The pseudo code for pacman and ghosts is given in Algorithm 1 and Algorithm 2. connectproxy ← pacman, ghost while true do positionpacman ← px, py, pangle positionghost ← gx, gy, gangle escape(positionpacman, positionghost ) if positioncurrent ≠ positioncurrent then drivepacman ← goFwd, turnRight/Left boundary_check(positionpacman, positionghost ) end end releaseconnection ← pacman, ghost
connectproxy ← pacman, ghost while true do positionpacman ← px, py, pangle positionghost ← gx, gy, gangle attack(positionpacman, positionghost ) if positioncurrent ≠ positioncurrent then driveghost ← goFwd, turnRight/Left boundary_check(positionpacman, positionghost ) end end releaseconnection ← pacman, ghost
Algorithm 1. Pseudo code for Pacman
Algorithm 2. Pseudo code for Ghost
In the physical implementation of the game, the network camera sends images of the map area where the robots are present. These images are processed for blob detection. The objects in videos or images have been treated as blobs in past also [9]. In blob detection red (ghost) and yellow (pacman) colors were identified. The global positions of the robots were determined using the blobs positions. The blob detection involves converting captured image from network camera to the HSV formatted image. In the HSV model, the luminous component i.e. brightness is decoupled from color-carrying information such as hue and saturation [10] So, the effect of sunlight or shadow on the blobs does not hamper the detection of colors. This format provided more consistent data to our experimental setup. The HSV values for colors red and yellow are provided. These converted HSV images are scaled with the thresholded image to get the final image with marks on yellow and red areas. Then, the moments of the thresholded image is calculated to get the positions of the blob. In mathematics, a moment is a quantitative measure of the shape of a set of points. [13] The pseudo-code for blob-detection is shown in Algorithm 3. The notations followed in the pseudo code for pacman and ghost, and in blob detection are explained in Table I. createsocket ← pacmanclient , ghostclient connect ← pacmanclient, ghostclient captureimage← image from camera proxy while true do 13
captureimage← image from camera proxy imagethresholded ← get_thresholded_image(captureimage) calculatemoments ← moments(imagethresholded) positionghost,pacman ← momentspacman, ghost sendposition(ghost,pacman) ← pacmanclient , ghostclient end releaseconnection ← pacmanclient, ghostclient Function get_thresholded_image(capture) imageHSV ← converimagetoHSV imagethreshold ← apply threshold to image imagethreshold ← apply HSV to imagethreshold return imagethreshold Algorithm 3. Pseudo Code for Blob-Detection TABLE I. LIST OF NOTATIONS connect {proxy} position_pacman position_ghost escape(position_pacman, position_ghost) drive(pacman/ghost) boundary_check(position_pacman, position_ghost) release_{connection} create_{socket}
establish a connection with robots. In simulation with the help of simulation clients and in physical with bluetooth adapter gives the x and y co-ordinates of pacman and angle of direction. gives the x and y co-ordinates of ghost and angle of direction. escape algorithm of pacman based on the distance with the ghost attack algorithm of ghost based on the distance with pacman check for corner areas in the map and then direction of movement is found with respect to pacman’s or ghost’s position releases the connection with the ghost and pacman to start client-socket communication between pac- man and ghost
IV. PLAYER/STAGE SIMULATION The simulation part of the project was done using Player/Stage, an open source simulation tool. The Player relies on a TCP client/server transport, in which devices reside in a server and a control program is a client to the server. To control a robot, the user first starts the player server, which listens on a particular TCP port (by default 6665), on the robot. A client program is initiated that establishes a TCP socket connection to the server. The client can run robot or any other machine that has a network connectivity to the robot. One client can connect to many servers and many clients can connect to one server using a multi client object [11]. Clients can be written in any programming language with support for TCP. In this project, the use of C language has been done. A. Multi-Client Architecture In this, the pacman is connected to two ghosts whose position2d clients are connected to ports 6665, 6666 and 6667 respectively. In the entire simulation environment there is need of one simulation proxy and one position2d proxy for each of the robots. The simulation proxy is same for all the robots and it is at port 6665. So, since the simulation is running at port 6665, all the robots are connected to the simulation via port 6665. Now, all the robots have a position2d proxy also with which they are able to know their own relative positions. The position2d proxies of pacman, ghost1 and ghost are 6665, 6666 and 6667 respectively. The management of maintaining two proxies (one for simulation and other for position2d) is done using playerc_mclient. The multi-client object manages connections to multiple server in parallel [12]. There are five experiments conducted in this environment using one pacman and two ghosts as shown in Figures 2-11. The experiments s done on a grid of 6x6. The experiments are conducted by changing the initial positions of the robots and then noticing their behaviour of judging the next moves as they reach towards the end of the game (when ghost is able to capture pacman). The yellow robot is pacman and red are ghosts. The average time taken by the robots to move between consecutive cells is 5 secs and the time to turn 90 degrees is 18 secs. The summary of all the results is shown in Table 2. The Time of Execution represents the total time taken by either of the ghosts to capture pacman. It can be seen from the results that experiment 4 demonstrated best performance since Ghost took more time to touch Pacman. In this experiment the Pacman was placed at the 14
A. Experiment 1
Figure 2. Initial Position
Figure 3. Final Position
B. Experiment 2
Figure 4. Initial Position
Figure 5. Final Position
C. Experiment 3
Figure 6. Initial Position
Figure 7. Final Position
center and two Ghosts’ were on one side as shown in Figure 8. Pacman had more room to escape on the other side. Note that Pacman was caught in other side of the area where Ghost’s were not initially present as shown in Figure 9. While, experiment 2 showed worst results as Pacman was caught in less time. In case of experiment 2, Pacman was in center of maze and two ghosts were set on the either side of the maze. So Pacman was caught by one of the Ghost easily as shown in Figure 5. 15
D. Experiment 4
Figure 8. Initial Position
Figure 9. Final Position
E. Experiment 5
Figure 10. Initial Position
Figure 11. Final Position
TABLE II. R ESULTS SUMMARY FOR M ULTI-CLIENT Experiment No. 1 2 3 4 5
Game Ended Yes Yes Yes Yes Yes
Time of Execution (in secs.) 58 32 60 70 35
B. Single-Client Architecture In this architecture two robots are used. Both robots are connected to port 6665 with position2d index being 0 and 1 respectively. It means that they are using only one port for both simulation and position2d proxy. The position2d proxy can have indexes referring to two devices connected to a single port. So, it means that both the robots are treated as two separate devices connected to a single port. The simulation proxy is also given on port 6665. This is implemented on a map area of 3X4 cells. Such a map area is taken to compare the results with the physical implementation of the iRobots. In the physical implementation the camera is able to capture an area equivalent to 3x4 cells. Five experiments were conducted in this environment by changing the initial positions of the robots in each experiment as shown in Figures 12-21. The yellow robot is pacman and red is a ghost. The average time taken by the robots to move between consecutive cells is 6 secs and the time to turn 90 degrees is 17 secs. The summary of all results for Single-Client architecture is shown in Table 3. Experiment 2 demonstrated more time for Ghost to catch Pacman and experiment 3 demonstrated less time for Ghost to catch Pacman. In experiment 3, there was less space left for the pacman to escape from ghost and hence was caught easily by Ghost. While, in Experiment 2, Pacman got a larger area to move around and make judgments. Hence Ghost took longer time to catch Pacman.
16
A. Experiment 1
Figure 12. Initial Position
Figure 13. Final Position
B. Experiment 2
Figure 14. Initial Position
Figure 15. Final Position
C. Experiment 3
Figure 16. Initial Position
Figure 17. Final Position
17
D. Experiment 4
Figure 18. Initial Position
Figure 19. Final Position
Figure 20. Initial Position
Figure 21. Final Position
E. Experiment 5
TABLE III. R ESULTS SUMMARY FOR SINGLE-C LIENT Experiment No. 1 2 3 4 5
Game Ended Yes Yes Yes Yes Yes
Time of Execution 1 min 55 secs 3 min 52 secs 52 secs 59 secs 58 secs
V. PHYSICAL IMPLEMENTATION A. Setup The following hardware setup was done to get the global positions of the robots. • Attach blobs of red and yellow color on pacman and ghost roomba robots. • Installation of D-Link 932-L network camera on ceiling to capture the game area. • Configure camera on the required port to get the images • Installation of g++ and running of blob detection code on it • Client-Socket programming to send the positions of pacman and ghost obtained from camera to the main algorithm. • Connection of Camera with LAN cable and iRobots using USB dongles. The dongles detect the MAC address of BAM modules on the iRobots. 18
B. Ghost was moving Pacman was static In this experiment pacman was held static while ghost was moving in different paths. Ghost was free to move in any direction and path to approach pacman. So, in this experiment it was found that ghost was able to approach pacman even when kept at different positions. There were five experiments conducted and in all of them ghost was able to reach pacman successfully. Here is a set of screen-shots taken from one of the five experiments to show the sequential movement of ghost in order to reach pacman
Figure 22. Position 1
Figure 23. Position 2
Figure 24. Position 3
Figure 25. Position 4
C. Pacman was moving Ghost was static In this experiment ghost was held static while pacman was moving in different paths. Pacman was free to move in any direction and path to go away from the ghost. So, in this experiment it was found that pacman was able to escape ghost even when kept at different positions. There were five experiments conducted and in all of them pacman was able to escape ghost successfully. Here is a set of screen-shots taken from one of the five experiments to show the sequential movement of pacman in order to escape from pacman.
Figure 26. Position 1
Figure 27. Position 2
19
Figure 28. Position 3
Figure 29. Position 4
D. Both Pacman and Ghost are moving In this case when both pacman and ghost were moving the results obtained were as expected from the prototype. The ghost and pacman were moving on the same path and direction as was obtained in simulation using attack and escape algorithms. The screen-shots of initial position and the path followed by pacman and ghost are shown in Figures 30-33.
Figure 30. Position 1
Figure 31. Position 2
Figure 32. Position 3
Figure 33. Position 4
The results for all the three experiments completed on Pacman and Ghost robots can be summarized in Table 4. TABLE IV. RESULTS OF E XPERIMENT ON ROBOTS Experiment Pacman Moving Ghost Moving Both Moving
Action Required Escape from Ghost Attack Pacman End Game
Result Obtained Successful Successful Successful
Time Taken (in secs) 50 40 30
VI. RESULTS AND ANALYSIS The prototype model of single-client and multi-client architecture using player/stage was implemented successfully. Pacman and Ghosts were able to make strategic moves in order to escape and attack each other. 20
The communication between the pacman and ghosts was established to provide global position of the robots. The single-client architecture was implemented on physical robots and verified via simulation. The following analysis was made with respect to the physical implementation of the game. • The physical implementation of Pacman game was completed using a network camera in a room. The blob detection on camera captured image, varied as illumination of the room differed. • Since the floor on which the game area has been made was textured which reduced the efficiency of blob detection. • The camera was able to capture an area equivalent to 3X4 cells, hence it reduced the scope of multiple robots to be placed in the game area. Also robot was covering 70% of the area in a given cell; hence tolerance levels for robotic movement was low. VII. CONCLUSIONS Despite having a few deviations in the results, a step towards realizing a game in robots was successfully implemented. This was a huge motivation towards realizing games in physical environment. Such kind of work encourages students to learn more on development and integration of software and hardware. This paper and work should lead to the realization of more games using physical robots. As a part of future work the following things can be included. • Placing some fruits for pacman to eat in the paths. These fruits can be in simulation as well as in physical environment in the form of drawings with different colors. The aim of pacman will be to reach to the fruits as well as avoid ghosts. On the other hand ghost will try to attack pacman and also reach the fruits in order to find pacman there. • Control of ghost can be done using joystick while the pacman will be moving using the algorithm. So, its aim will be to detect ghost’s position and then try to escape from it. • The obstacles can be made moving in real-time. This will help students to develop more real-time path planning algorithms for Pacman and Ghost. • With a bigger area being captured, multiple ghosts can be introduced in the game area. REFERENCES [1] Henrik Hautop Lund, “AI in children’s play with lego robots,” Proceedings of AAAI 1999 Spring Symposium Series, AAAI Press, Menlo, 1999. [2] Namco Bandai Games Inc., Bandai Namco press release for 25th Anniversary Edition (in Japanese), bandainamcogames.co.jp/. [3] Tony Long, “Pac-Man Brings Gaming Into Pleistocene Era”, October 10, 1979 [4] Anderson M. and Thaete L., Wieg N., “Player/stage: A unifying paradigm to improve robotics education delivery”,2007 [5] Rao M. , “AN IMPLEMENTATION OF PACMAN GAME USING ROBOTS”, Indian Journal of Computer Science and Engineering (IJCSE), vol. 2 no. 6, December 2011. [6] Josh F., Cheryl S. and William S, “A video game-based mobile robot simulation environment”, Intelligent Robots and Systems, IEEE/RSJ International Conference , pp. 3749-3754, October 2006. [7] Cowley B., Charles D., Black M. and Hickey, R., “Analyzing player behavior in pacman using feature-driven decision theoretic predictive modeling”, Computational Intelligence and Games, IEEE Symposium, pp. 170 177, September 2009. [8] Player Stage Documentation on position2d, http://playerstage.sourceforge.net/doc/Playercvs/player/group_playerc_proxy_position2d.html [9] Kefalea, E., “Object localization and recognition for a grasping robot,” Industrial Electronics Society, Proceedings of the 24th Annual Conference of the IEEE, vol. 4, pp. 2057-2062, September 1998. [10] Wen Chen1, Yun Q. Shi1 and Guorong Xuan2, “IDENTIFYING COMPUTER GRAPHICS USING HSV COLOR MODEL AND STATIS- TICAL MOMENTS OF CHARACTERISTIC FUNCTIONS”, IEEE Inter- national Conference on Multimedia and Expo, pp. 1123 - 1126, 2007. [11] Richard T. Vaughan and Brian P. Gerkey, “Reusable robot code and the player/stage project in Software Engineering for Experimental Robotics”, Springer-Verlag, pp.267-289. 2006. [12] Player Stage Documentation on Multi Client object, http://playerstage.sourceforge.net/doc/Playercvs/player/group_multiclient.html#details [13] Kenney, J. F. and Keeping, E. S. "Moments About the Origin." §7.2 in Mathematics of Statistics, Pt. 1, 3rd ed. Princeton, NJ: Van Nostrand, pp. 91-92, 1962.
21