+24 -17

docs/briscola_chiamata/bc-doc.tex

reviewed

··· 35 35 36 36 2-APL stands for A Practical Programming Language , and is developed at the University of Utrecht as an academic tool for developing intelligent multi-agent systems. With its unique feature of integrating a declarative and an imperative style programming and the ability to use the JADE platform, 2APL is a resourceful environment to program in. 37 37 38 38 - In a previous Paper we described the features of 2APL, along with a more formal description of the language. Its tools were presented and a few examples were showcased to see some agents in action.The aim of this Paper is to present our own prototype of a 2APL multiagent system to model the card game of Briscola Chiamata. 38 38 + In a previous Paper we described the features of 2APL, along with a more formal description of the language. Its tools were presented and a few examples were showcased to see some agents in action.The aim of this Paper is to present our own prototype of a 2APL multi-agent system to model the card game of Briscola Chiamata. 39 39 40 40 - There are many features that make Briscola Chiamata an ideal game to model with a multiagent system. The way the game works forces the developer to give agents cooperation, while at the same time being competitive; they have to be reactive, but also proactive; finally they need to also be autonomous and social. 40 40 + There are many features that make Briscola Chiamata an ideal game to model with a multi agent system. The way the game works forces the developer to give agents cooperation, while at the same time being competitive; they have to be reactive, but also proactive; finally they need to also be autonomous and social. 41 41 42 42 Cooperation in Briscola Chiamata is a double-edge sword, since if you choose the wrong player to cooperate with, you will be the cause of your own defeat. On the other hand, a successful cooperation will most of the time ensure a safe victory. This risk in choosing who to trust and cooperate with is what makes the game exciting for humans, and hard for agents.Competition is divided into two types, an individual agent competing to win the game, and a team of agents, trying to compete against the opposite team. 43 43 44 44 Reactivity is an obvious requirement in any group game; when it is your turn to play, you have to play. In Briscola Chiamata however a Proactivity is also required since players need to bid only if they desire and the turns are non strict, i.e: a player can decide to play outside his turn. This freedom of the game needs to be given to the agents. 45 45 46 46 - The social factor comes from the fact that players have to interact with each other in order to advance the game. The bidding system each round of the game and the fact that teams are created without the agents knowing who they are partners with creates the necessity for communication between them in order to try and determine who this partner is. Having agents change status from partner to opponent between rounds makes a dynamic social multiagent system which is worth studying. 46 46 + The social factor comes from the fact that players have to interact with each other in order to advance the game. The bidding system each round of the game and the fact that teams are created without the agents knowing who they are partners with creates the necessity for communication between them in order to try and determine who this partner is. Having agents change status from partner to opponent between rounds makes a dynamic social multi agent system which is worth studying. 47 47 48 48 The rest of the report is organized as follows. Section~\ref{sec:gamedescr} a description of the game. In the next sections we follow the Prometheus design methodology to create our system where the the System Specification phase is illustrated in Section~\ref{sec:sysspec}, the High-level (Architectural) Design in Section~\ref{sec:highdesign} and Detailed Design in Section~\ref{sec:detaildesign}. Finally, we display the built prototype in Section~\ref{sec:proto} and we conclude the paper in Section~\ref{sec:concl} with some remarks, related works and conclusions on the overall success of the prototype. 49 49 50 50 \section{Game Description}\label{sec:gamedescr} 51 51 52 52 Briscola Chiamata is the five-player version of Briscola. Every player is dealt eight cards, so that no cards remain undealt. Then, each player, starting from the dealer's right\footnote{If the dealer is not one the players, then starting from the declearer's right.} and proceeding counter-clockwise, bids in an auction to declare how many points they will score. A player may pass, and hence cannot bid again in that game. The bid represents the number of points that player believes he is capable of accumulating. Bidding continues until all but one player have passed in a round. This remaining player has then "won the bid" and therefore gets to declare the Briscola. The declarer also declares a specific Briscola card (example, the ``Ace of Cups'' if Cups was the declared Briscola) and the holder of this card is then determined to be the declarer's partner. Logically, the declarer would declare the highest Briscola card he does not already hold in the hopes of creating the strongest combined hand between him and his partner. 53 53 - The remaining three players are partnered with each other, without their knowledge. Each player, other than the declarer's partner, acts independently, until it is clear which players are partners. Infrequently, the declarer may declare a Briscola card he already holds (if he feels he has a very strong hand), in which case the other four players are partenered against him. 53 53 + The remaining three players are partnered with each other, without their knowledge. Each player, other than the declarer's partner, acts independently, until it is clear which players are partners. Infrequently, the declarer may declare a Briscola card he already holds (if he feels he has a very strong hand), in which case the other four players are partnered against him. 54 54 Game strategy is often devised to determine which player is partnered with the declarer, whereas the declarer's partner may devise ruses and decoy strategies to fool the other players, such as not taking a trick, or playing points on a trick that will be won by an opponent. 55 55 56 56 \paragraph{Scoring} ··· 75 75 76 76 Here follows a brief description of each of them: 77 77 \begin{itemize} 78 78 - \item ``Start the game Scenario'' is in charge of receveing join requests from users and accept and subscribe users or queue their requests. Once there are 5 players registered in the system. 78 78 + \item ``Start the game Scenario'' is in charge of receiving join requests from users and accept and subscribe users or queue their requests. Once there are 5 players registered in the system. 79 79 \item ``Dealing scenario'' is in charge of choosing the dealer, shuffle the deck and deal cards to all subscribed the players in the system. 80 80 \item ``Bidding scenario'' takes place once the dealing is over. It is in charge of giving players a chance to bid. The player who wins the bid, must declare the Briscola card. If nobody bids, then the game has to be restarted. If the bidding succeeds, the Briscola card is declared by the winner of the bid. 81 81 \item ``Play the game'' scenario occurs once all bids are over and the game finally starts. The team distributions are obviously unknown to all players until the Briscola card is played. The players have to update their beliefs about the team distributions each time a card is played. Of course, cheating is part of the game. Communication that is used to model sign exchange among players is allowed to exchange information about players and cards. After each round, points are counted. ··· 116 116 117 117 \subsection{Scenarios Diagram} 118 118 119 119 - The scenarions diagram provided in Figure~\ref{fig:scenarios} shows the dynamics of the game. The scenarios cover all the phases of the game. First, the ``start the game scenario'' waits for players to register in the system, then the ``dealing scenario'' deals cards to the players, after that the ``bidding scenario'' allows the players to do their bids, then ``play the game scenario'' allows them to play the gam and finally the ``end the game scenario'' assigns them their socre. If nobody of the players leave the system, another game can be started, again from the ``dealing scenario''. 119 119 + The scenarios diagram provided in Figure~\ref{fig:scenarios} shows the dynamics of the game. The scenarios cover all the phases of the game. First, the ``start the game scenario'' waits for players to register in the system, then the ``dealing scenario'' deals cards to the players, after that the ``bidding scenario'' allows the players to do their bids, then ``play the game scenario'' allows them to play the game and finally the ``end the game scenario'' assigns them their score. If nobody of the players leave the system, another game can be started, again from the ``dealing scenario''. 120 120 121 121 \begin{figure}[htp] 122 122 \includegraphics[keepaspectratio,scale=0.5]{pdt/images/system_specification/scenarios.png} ··· 136 136 137 137 \subsection{System Roles Diagram} 138 138 139 139 - The next stage of the process is to group similar goals together into roles. Each role should be limited in scope, and be able to be described fully be 1-2 sentences. In a system roles diagram, we group different goals, percepts and actions under roles. This helps in further modularizing the system into functionality. The input is represented as a percept and the output as an action. Figure~\ref{fig:sysroles} shows our system roles diagram for the game. As stated, the description of each role can be given in a short sentence and they are quite obvious. The ``starting game role'' manages join requests, ``identify the dealer role'' identifies the dealer in the system, ``dealing role'' shuffle and deal cards, ``bidding role'' manage bids, ``declaring briscola role'' is used to declare the briscola card, ``turn control role'' decides player's turn to play, ``playing role'' is used to play cards, ``team setting role'' try to infer team settings, ``counting points role'' counts points for each rounds, ``declare the winner role'' declares the winner team of the game, ``update score points'' updates the score table while ``release the player'' release the players from the system. 139 139 + The next stage of the process is to group similar goals together into roles. Each role should be limited in scope, and be able to be described fully be 1-2 sentences. In a system roles diagram, we group different goals, percepts and actions under roles. This helps in further modularizing the system into functionality. The input is represented as a percept and the output as an action. Figure~\ref{fig:sysroles} shows our system roles diagram for the game. As stated, the description of each role can be given in a short sentence and they are quite obvious. The ``starting game role'' manages join requests, ``identify the dealer role'' identifies the dealer in the system, ``dealing role'' shuffle and deal cards, ``bidding role'' manage bids, ``declaring Briscola role'' is used to declare the briscola card, ``turn control role'' decides player's turn to play, ``playing role'' is used to play cards, ``team setting role'' try to infer team settings, ``counting points role'' counts points for each rounds, ``declare the winner role'' declares the winner team of the game, ``update score points'' updates the score table while ``release the player'' release the players from the system. 140 140 141 141 \begin{figure}[htp] 142 142 \includegraphics[keepaspectratio,scale=0.4]{pdt/images/system_specification/system_roles.png} ··· 150 150 151 151 \subsection{Data Coupling Diagram} 152 152 153 153 - The roles that were formed in the last step of the previous phase are linked to data that has been identified as necessary for performing that role. In the data-coupling diagram you can see all roles and data types in the system. The following data types have been identified in the system: ``position'' that record the position of the player at the table that is useful to decide its turn, the ``deck'' that contains all the cards, the ``hand'' that represents the cards in hand of each player, the ``historic of bids'' that records the historic of bids, the ``historicic of card played'' that analogusly records the historic of card played in order to decide which card to play, the ``team information'' that is used to store beliefs about team settings, the ``points'' that is used to store the points of each round and finally the ``scoreboard'' that contains the all the times score of the games for each player. The data coupling diagram is provided in Figure~\ref{fig:datacoupl}. 153 153 + The roles that were formed in the last step of the previous phase are linked to data that has been identified as necessary for performing that role. In the data-coupling diagram you can see all roles and data types in the system. The following data types have been identified in the system: ``position'' that record the position of the player at the table that is useful to decide its turn, the ``deck'' that contains all the cards, the ``hand'' that represents the cards in hand of each player, the ``historic of bids'' that records the historic of bids, the ``historicic of card played'' that analogously records the historic of card played in order to decide which card to play, the ``team information'' that is used to store beliefs about team settings, the ``points'' that is used to store the points of each round and finally the ``scoreboard'' that contains the all the times score of the games for each player. The data coupling diagram is provided in Figure~\ref{fig:datacoupl}. 154 154 155 155 \begin{figure}[htp] 156 156 \includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/data_coupling.png} ··· 252 252 253 253 \section{Prototype}\label{sec:proto} 254 254 255 255 - The Prototype was built following the Prometheus design, and as described in the previous sections, each step was carefully defined, built and implmented. The idea was to use as many features as 2APL as possible, and thus our own personal environment was also created for this Paper.The prototype can therefore be logically separated in two parts : Firstly the environment in which the agents interact, and secondly the agents themselves. 255 255 + The prototype was built following the Prometheus design as described in the previous sections, each step was carefully defined, built and implemented. % The idea was to use as many features as 2APL as possible, and thus our own personal environment was also created for this Paper. 256 256 + The prototype can be logically separated in two parts: firstly the environment in which the agents interact, and secondly the agents themselves. 257 257 + 258 258 + Environments in 2APL, as previously mentioned, are created as a Java class extension. By using the example environment given in the documentation of 2APL we were able to build our own environment adding it a graphic user interface (GUI) to allow researchers to see the agents in action. This environment was built so that it would allow agents to interact in all of the possible manners defined during the design stage. We successfully implemented it and achieved the desired level of detail as to be pleasing to the eye but not a burden to the real task at hand: the way the agents act and interact. A screen shot of the GUI can be seen in Figure~\ref{fig:gui1} . As you can see it was decided to split the GUI into three panels: the left panel being the one which shows each players cards, score and bid; a top right corner in which cards played are shown, and a bottom right panel in which information about the agent interactions is displayed, along with game information. 256 259 257 257 - Environments in 2APL, as previously mentioned, are created as a Java class extension. By using the example environment given in the documentation of 2APL we were able to build our own graphic user interface to allow researchers to see the agents in action. This environment was built so that it would allow agents to interact in all of the possible manners defined during the design stage, but also to manage the addition and removal of agents. We succesfully implemented it and achieved the desired level of detail as to be pleasing to the eye but not a burden to the real task at hand : the way the agents act and interact. A screenshot of the GUI can be seen in figure 6.1 . As you can see it was decided to split the program into three panels : The left panel being the one which shows each players cards, score and bid; a top right corner in which cards played are shown, and a bottom right panel in which information about the agent interactions is displayed, along with game information. 260 260 + \begin{figure}[htp] 261 261 + \includegraphics[keepaspectratio,scale=0.3]{fig/gui1.png} 262 262 + \label{fig:gui1} 263 263 + \caption{Screenshot from the graphical user interface} 264 264 + \end{figure} 258 265 259 259 - The Agents were designed separetely using prolog, and saved in separate files depending on the strategy they were programmed to have. Since there are five players in a Briscola Chiamata game, we were able to have up to five agents having different strategies fighting against each other and we would be able to see the victorious strategy. Even though prolog is mainly used to create the Agent, it is of limited use in the belief base and the usage of extra libraries could give the user more freedom when designing them (and stronger strategies too). In figure 6,2 you can see a sample agent that was used in our prototype along with its settings. 266 266 + %The agents were designed separately using prolog, and saved in separate files depending on the strategy they were programmed to have. 267 267 + Since there are five players in a Briscola Chiamata game, we were able to have up to five agents having different strategies fighting against each other and we would be able to see the victorious strategy. Even though Prolog is mainly used to create the agent, it is of limited use in the belief base and the usage of extra libraries could give the user more freedom when designing them (and stronger strategies too). 260 268 261 261 - The prototype however, as its name indicates, is marely a prototype and thus implements the most simplistic aspects . The agents were implemented to follow straight forward strategies with very little cooperation and even "cheating" in order to find their partners during a game round. It is worth mentioning that during the testing part, the 2APL parser was in most cases completely uselesss as the error messages it provides as feedback are unclear and unhelpful. This makes the task of perfectioning the prototype hard and tidious. Finally it is worth mentioning that this prototype was built so that it could easely be extended.For example it could be extended into an application which accepts both human and agent players, and even further to be played using a network and/or the internet in order to fight other agents. 269 269 + The prototype however, as its name indicates, is merely a prototype and thus implements the most simplistic aspects . The agents were implemented to follow straight forward strategies with very little cooperation and even ``cheating'' in order to find their partners during a game round. It is worth mentioning that during the testing part, the 2APL parser was in most cases completely useless as the error messages it provides as feedback are unclear and unhelpful. This makes the task of perfectioning the prototype hard and tedious. Finally it is worth mentioning that this prototype was built so that it could easily be extended. For example it could be extended into an application which accepts both human and agent players, and even further to be played using a network and/or the internet in order to fight other agents. 262 270 263 271 We would have loved to add some of those more advanced features such as having completely radical strategies fighting each other, or even some form of reinforcement learning would have been fantastic to see in action, but time and the difficulty of extending things in 2APL have made it impossible have made this impossible. 264 264 - 265 272 266 273 \section{Conclusion}\label{sec:concl} 267 274 268 268 - The general feeling after implementing the briscola game into the 2APL system is both good and bad. I will start with the positive aspects. 275 275 + The general feeling after implementing the Briscola Chiamta game into the 2APL system is both good and bad. We will start with the positive aspects. 269 276 270 277 Having a declarative programming when developing agents certainly gives the designer more freedom and a certain level of confidence that you would not have with other languages. You can focus specifically on 'what' you want your agents to do and not 'how'. This conceptual division is one of the main attractions of 2APL and even though some of us required to learn this type of programming in more depth as we had no previous experience in it, we certainly appreciated the benefit gained when we were in the implementation stage. 271 278 272 279 The JADE platform tools and some of 2APL tools were certainly helpful from beginning to end and provided us with information that would have otherwise been hard to see or find. Of course we can connect any of our agents to any other agent in the JADE platform and having portability is a helpful and important feature. 273 280 274 274 - The negative aspects of 2APL are few, but certainly big. Firstly it is clearly a tool for research and not for real development. The documentation for 2APL has been ignored by its developers for far too long, it is simplistic , undetailed and the examples shown are ...one (which is not even fully explained!).The environment we built was done by scanning the code of some of the java classes of an example and thus we lacked the true ability to implement a full application (this was never our intention, but knowing that if you wanted it would be very difficult certainly isnt a positive aspect). 281 281 + The negative aspects of 2APL are few, but certainly big. Firstly it is clearly a tool for research and not for real development. The documentation for 2APL has been ignored by its developers for far too long, it is simplistic , undetailed and the examples shown are ...one (which is not even fully explained!).The environment we built was done by scanning the code of some of the Java classes of an example and thus we lacked the true ability to implement a full application (this was never our intention, but knowing that if you wanted it would be very difficult certainly isn't a positive aspect). 275 282 276 276 - Even though prolog does give us a very powerful logic system, it does lack other tools such as databases, load data and other form of operation in which a prolog library would be required (and not allowed in 2APL).Finally, even though it was previously mentioned, the 2APL parser was so unhelpful that it barely provided us with any useful information. Clearer instructions or error messages would be necessary if any serious development was to be made in this language. 283 283 + Even though prolog does give us a very powerful logic system, it does lack other tools such as databases, load data and other form of operation in which a prolog library would be required (and not allowed in 2APL). Finally, even though it was previously mentioned, the 2APL parser was so unhelpful that it barely provided us with any useful information. Clearer instructions or error messages would be necessary if any serious development was to be made in this language. 277 284 278 278 - So even though we praised 2APL for some things and despised it for others, as a whole we were pleased to develop with 2APL and do believe that with more work it can become the "go to" language of multiagent systems... at least from a research point of view. 285 285 + So even though we praised 2APL for some things and despised it for others, as a whole we were pleased to develop with 2APL and do believe that with more work it can become the "go to" language of multi agent systems... at least from a research point of view. 279 286 280 287 281 288 \section{Bibliography}

docs/briscola_chiamata/fig/gui1.png

reviewed

This is a binary file and will not be displayed.