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.

1. 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
Proc. of Int. Conf. on Recent Trends in Information, Telecommunication and Computing, ITC

2. 12
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

3. 13
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
Algorithm 1. Pseudo code for Pacman
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 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

4. 14
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} establish a connection with robots. In simulation with the help of
simulation clients and in physical with bluetooth adapter
position_pacman gives the x and y co-ordinates of pacman and angle of direction.
position_ghost gives the x and y co-ordinates of ghost and angle of direction.
escape(position_pacman,
position_ghost)
escape algorithm of pacman based on the distance with the ghost
drive(pacman/ghost) attack algorithm of ghost based on the distance with pacman
boundary_check(position_pacman,
position_ghost)
check for corner areas in the map and then direction of movement is
found with respect to pacman’s or ghost’s position
release_{connection} releases the connection with the ghost and pacman
create_{socket} 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

5. 15
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.

6. D. Experiment 4
Figure 8. Initial Position Figure 9. Final Position
E. Experiment 5
Figure 10. Initial Position Figure 11. Final Position
TABLE II. RESULTS SUMMARY FOR MULTI-CLIENT
Experiment No. Game Ended Time of Execution (in secs.)
1 Yes 58
2 Yes 32
3 Yes 60
4 Yes 70
5 Yes 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

7. 17
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

8. 18
D. Experiment 4
Figure 18. Initial Position Figure 19. Final Position
E. Experiment 5
Figure 20. Initial Position Figure 21. Final Position
TABLE III. RESULTS SUMMARY FOR SINGLE-CLIENT
Experiment No. Game Ended Time of Execution
1 Yes 1 min 55 secs
2 Yes 3 min 52 secs
3 Yes 52 secs
4 Yes 59 secs
5 Yes 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.

9. 19
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

10. 20
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 EXPERIMENT ON ROBOTS
Experiment Action Required Result Obtained Time Taken (in secs)
Pacman Moving Escape from Ghost Successful 50
Ghost Moving Attack Pacman Successful 40
Both Moving End Game Successful 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.

11. 21
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/Player-
cvs/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/Player-
cvs/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.