2-APL UPC project.
docs almost done 2
+88
-51
+14
docs/briscola_chiamata/bc-doc.bib
+14
docs/briscola_chiamata/bc-doc.bib
···
25
25
address = {New York, NY, USA},
26
26
}
27
27
28
+
@techreport{13559521,
29
+
author = {Fiz, Beltran Borja and De Santis, Fabrizio and Gabarda, Marcos},
30
+
title = {2APL: A Practical Programming Language and Platform for Multi-Agent Systems},
31
+
year = {2009},
32
+
}
33
+
34
+
@misc{ wiki:briscola,
35
+
author = "Wikipedia",
36
+
title = "Briscola --- Wikipedia{,} The Free Encyclopedia",
37
+
year = "2010",
38
+
url = "\url{http://en.wikipedia.org/w/index.php?title=Briscola&oldid=336665493}",
39
+
note = "[Online; accessed 11-January-2010]"
40
+
}
41
+
+73
-51
docs/briscola_chiamata/bc-doc.tex
+73
-51
docs/briscola_chiamata/bc-doc.tex
···
8
8
\usepackage{tabularx}
9
9
\usepackage{amssymb}
10
10
\usepackage{amsmath}
11
+
\usepackage{subfig}
11
12
12
13
\begin{document}
13
14
···
33
34
34
35
\section{Introduction}\label{sec:intro}
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
+
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 platform to program in.
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 multi-agent system to model the card game of Briscola Chiamata.
39
+
In a previous report\cite{13559521} we described the features of 2APL, along with both formal and operational description of the language. Its tools were presented and a few examples were showcased to see some agents in action. The aim of this report is to present the design and our own prototype of a 2APL multi-agent system to model the card game of Briscola Chiamata.
39
40
40
41
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
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
+
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 which players 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 alone, and a team of agents, that are unknown for mostly of the game, trying to compete against the opposite team.
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
+
Reactivity is an obvious requirement in any card game; when it is your turn to play, you have to play. In Briscola Chiamata however a proactivity is also required since turns are non strict, i.e: a player can decide to play outside his turn to cheat others of not being interested in the current round. This freedom of the game needs to be given to the agents.
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 multi agent system which is worth studying.
47
+
The social factor comes from the fact that teams are created without the agents knowing who they are partners and this creates the necessity for communication between them in order to try to determine who are their partners. This, of course, implies a balance between cooperating and cheating. Having agents change status from partner to opponent between rounds makes a dynamic social multi agent system which is worth studying.
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 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
+
The rest of the report is organized as follows. Section~\ref{sec:gamedescr} provides a detailed description of the game. Section~\ref{sec:sysspec},~\ref{sec:highdesign},~\ref{sec:detaildesign} respectively introduces the system specification, architectural design and detailed design of our system following the \emph{Prometheus} design methodology. Finally, we display the built prototype in Section~\ref{sec:proto} and we conclude the report in Section~\ref{sec:concl} with some remarks, related works and conclusions on the overall success of the prototype.
49
50
50
51
\section{Game Description}\label{sec:gamedescr}
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
+
Briscola Chiamatais the five-player version of the italian game of Briscola\cite{wiki: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'') 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
54
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
55
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
56
56
57
\paragraph{Scoring}
57
58
58
-
Each player collects tricks as per the regular version of the game, and counts points collected similarly. Partners, which are known by the end of the game, then combine their points. Game points are assigned as follows: if the declarer and partner accumulate card points greater than or equal to the points that were declared after the bidding process, then the declarer earns two game points, the partner earns one game point and the other players each lose one game point. If the declarer and partner accumulate fewer card points than declared, then the declarer loses two game points, the partner loses one game point and the other players each earn one game point. These points are accumulated after every game. The grand winner is the player with the most points at the end of the last match. Note that if the declarer calls a Briscola he holds, then the declarer will win or lose four points, and every other player will win or lose one point.
59
+
Each player collects tricks as per the regular version of the game, and counts points collected similarly. Partners, which are known by the end of the game (when briscola card is dealt), then combine their points. Game points are assigned as follows: if the declarer and partner accumulate card points greater than or equal to the points that were declared after the bidding process, then the declarer earns two game points, the partner earns one game point and the other players each lose one game point. If the declarer and partner accumulate fewer card points than declared, then the declarer loses two game points, the partner loses one game point and the other players each earn one game point. These points are accumulated after every game. The grand winner is the player with the most points at the end of the last match. Note that if the declarer calls a Briscola he holds, then the declarer will win or lose four points, and every other player will win or lose one point.
59
60
60
61
\section{System Specification}\label{sec:sysspec}
61
62
62
-
In this phase, actors (human or software) expected to interact with the system, are identified, along with the interface to the system in terms of actions and percepts; system goals are elaborated, and scenarios described in terms of sequences of steps are developed. Roles encompassing small chunks of functionality (identified by goals, percepts and actions) are described and captured.
63
+
According to Prometheus methodoly, in the system specification phase, the actors expected to interact with the system, are identified, along with the interface to the system in terms of actions and percepts; system goals are elaborated, and scenarios described in terms of sequences of steps are developed. Roles encompassing small chunks of functionality (identified by goals, percepts and actions) are described and captured.
63
64
64
65
\subsection{Analysis Overview Diagram}
65
66
66
-
The analysis overview diagram is designed to show the interactions between the system and the environment. At this abstract level it is necessary to identify the actors, scenarios, percepts and actions involved in the system. This consists of a two step process. Firstly, we identify the actors and the scenarios they participate in with the system. Secondly, we identify and define the actions and percepts between the actors and the system. Figure~\ref{fig:analysis} provides the analysis overview diagram for our game.
67
+
The analysis overview diagram is designed to show the interactions between the system and the environment. At this abstract level it is necessary to identify the actors, scenarios, percepts and actions involved in the system. This consists of a two step process. Firstly, we identify the actors and the scenarios they participate in with the system. Secondly, we identify and define the actions and percepts between the actors and the system.
67
68
68
-
\begin{figure}[htp]
69
-
\includegraphics[keepaspectratio,scale=0.35]{pdt/images/system_specification/analysis_overview.png}
70
-
\label{fig:analysis}
71
-
\caption{Analysis overview diagram}
72
-
\end{figure}
73
-
74
-
The actors are the people or all external systems associated with the system that we can model in our game as the User of the system. The scenarios are the processes which the system uses to handle the percepts and produce the actions. The percepts are all the types information which come into the system from the environment. The actions is everything that is sent from the system to the environment.
75
-
76
-
Here follows a brief description of each of them:
69
+
The only actor we felt to model in this first sketch of our game is the user of the system that can be either human or software. Here follows a brief description of each of the scenarios we have identified for it:
77
70
\begin{itemize}
78
71
\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
72
\item ``Dealing scenario'' is in charge of choosing the dealer, shuffle the deck and deal cards to all subscribed the players in the system.
···
114
107
\caption{Summary of percepts and actions in the system}
115
108
\end{table}
116
109
110
+
111
+
\begin{figure}[htp]
112
+
\centering
113
+
\includegraphics[keepaspectratio,scale=0.35]{pdt/images/system_specification/analysis_overview.png}
114
+
\label{fig:analysis}
115
+
\caption{Analysis overview diagram}
116
+
\end{figure}
117
+
118
+
Figure~\ref{fig:analysis} provides the analysis overview diagram for our game.
119
+
120
+
117
121
\subsection{Scenarios Diagram}
118
122
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''.
123
+
The scenarios cover all the phases of the game shows the dynamics 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''. The scenarios diagram is provided in Figure~\ref{fig:scenarios} .
120
124
121
125
\begin{figure}[htp]
126
+
\centering
122
127
\includegraphics[keepaspectratio,scale=0.5]{pdt/images/system_specification/scenarios.png}
123
128
\label{fig:scenarios}
124
129
\caption{Scenarios diagram}
···
126
131
127
132
\subsection{Goals Diagram}
128
133
129
-
The goal overview diagram is a directed acyclic graph of all goals in the system showing how goals can be decomposed into subgoals. Sub-goals can be generated by asking ``how will the system accomplish this goal'' Parent goals can be generated by asking ``why does the system accomplish this goal''. Figure~\ref{fig:goals} shows our goals diagram for the game.
134
+
The goal overview diagram is a directed acyclic graph of all goals in the system showing how goals can be decomposed into subgoals. Sub-goals can be generated by asking ``how will the system accomplish this goal'' while parent goals can be generated by asking ``why does the system accomplish this goal''. Figure~\ref{fig:goals} shows our goals diagram for the game.
130
135
131
136
\begin{figure}[htp]
137
+
\centering
132
138
\includegraphics[keepaspectratio,scale=0.4]{pdt/images/system_specification/goal_overview.png}
133
139
\label{fig:goals}
134
140
\caption{Goals diagram}
···
136
142
137
143
\subsection{System Roles Diagram}
138
144
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. Here follows the descriptions:
145
+
In the 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. Each role should be limited in scope, and be able to be described fully be 1-2 sentences. According to this principle, here follows the descriptions we have identified:
140
146
\begin{itemize}
141
147
\item ``Starting game role'' manages the join requests
142
148
\item ``Identify the dealer role'' identifies who is the dealer in the game
···
153
159
\end{itemize}
154
160
155
161
\begin{figure}[htp]
162
+
\centering
156
163
\includegraphics[keepaspectratio,scale=0.4]{pdt/images/system_specification/system_roles.png}
157
164
\label{fig:sysroles}
158
165
\caption{System roles diagram}
159
166
\end{figure}
160
167
168
+
\newpage
169
+
161
170
\section{Architectural Design}\label{sec:highdesign}
162
171
163
172
In this phase, the agent types that will exist in the system are defined by combining roles, the overall structure of the system is described using a system overview diagram, and interaction protocols are used to capture the dynamics of the system in terms of legal message sequences.
164
173
165
174
\subsection{Data Coupling Diagram}
166
175
167
-
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. Here follows the list of the data types that have been identified in the system:
176
+
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. Here follows the list of the data types that have been identified in the system:
168
177
\begin{itemize}
169
178
\item ``Position'' that record the position of the player at the table that is useful to decide its turn
170
179
\item ``Deck'' that contains all the cards
···
179
188
The data coupling diagram is provided in Figure~\ref{fig:datacoupl}.
180
189
181
190
\begin{figure}[htp]
191
+
\centering
182
192
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/data_coupling.png}
183
193
\label{fig:datacoupl}
184
194
\caption{Data coupling diagram}
···
186
196
187
197
\subsection{Agent-Role Grouping Diagram}
188
198
189
-
In this diagram we group the roles into agent types. Decisions regarding how to group depend on role similarity, as well as analysis of data usage. The agent-role coupling diagram shows the group of roles that come under an agent. Here follows the list of the agent types that we have indentified:
199
+
In this diagram we group the roles into agent types. The agent-role coupling diagram shows the group of roles that come under an agent. Here follows the list of the agent types that we have indentified:
190
200
\begin{itemize}
191
201
\item ``Dealer'' that is the that represents the dealer that is in charge of dealing cards
192
202
\item ``Gatekeeper'' that is the that represents the agent that let the players come in and out the system
···
197
207
Figure~\ref{fig:agentrole} provides the agent-role grouping diagram for our game.
198
208
199
209
\begin{figure}[htp]
210
+
\centering
200
211
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/aget-role_grouping.png}
201
212
\label{fig:agentrole}
202
213
\caption{Agent-role grouping diagram}
···
207
218
In the agent acquaintance diagram you can see all agents within the system and which agents interact. The agent acquaintance diagram is provided in Figure~\ref{fig:agentacq}.
208
219
209
220
\begin{figure}[htp]
221
+
\centering
210
222
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/agent_acquaintance.png}
211
223
\label{fig:agentacq}
212
224
\caption{Agent acquaintance diagram}
···
217
229
In the system overview diagram you can see all agents in the system, along with their interface and interactions. The system overview diagram is provided in Figure~\ref{fig:sysovervw}.
218
230
219
231
\begin{figure}[htp]
232
+
\centering
220
233
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/system_overview.png}
221
234
\label{fig:sysovervw}
222
235
\caption{System overview diagram}
···
224
237
225
238
\section{Detailed Design}\label{sec:detaildesign}
226
239
227
-
In this phase, the internals of each agent are developed in terms of capabilities, events, plans and data. Detailed Design is done at the level of individual agents.
240
+
In this phase, the internals of each agent are developed in terms of capabilities, events, plans and data at the level of individual agents.
228
241
229
242
\subsection{Agent Overview Diagram}
230
-
The agent overview diagram shows the internals of an agent. There is one agent overview diagram for every agent in the system: the dealer, the gatekeeper, the 5 non-player character and the notary. Diagrams for each of them are provided in Figure~\ref{fig:dealer}, Figure~\ref{fig:notary}, Figure~\ref{gatekeeper} and Figure~\ref{fig:nonplay-char}.
243
+
The agent overview diagram shows the internals of an agent. Thus, there is one agent overview diagram for every agent in the system: the dealer, the gatekeeper, the 5 non-player character and the notary. Their diagrams are respectively provided in Figure~\ref{fig:dealer}, Figure~\ref{fig:notary}, Figure~\ref{fig:gatekeeper} and Figure~\ref{fig:nonplay-char}.
231
244
232
245
\begin{figure}[htp]
246
+
\centering
233
247
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/dealer_overview_diagram.png}
234
248
\label{fig:dealer}
235
249
\caption{Agent overview diagram for the dealer agent}
236
250
\end{figure}
237
251
\begin{figure}[htp]
252
+
\centering
238
253
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/notary_overview_diagram.png}
239
254
\label{fig:notary}
240
255
\caption{Agent overview diagram for the notary agent}
241
256
\end{figure}
242
257
\begin{figure}[htp]
258
+
\centering
243
259
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/gatekeeper_overview_diagram.png}
244
260
\label{fig:gatekeeper}
245
261
\caption{Agent overview diagram for the gatekeeper agent}
···
252
268
253
269
254
270
\subsection{Capability Overview Diagram}
255
-
The capability overview diagram allows you to specify the internals of a capability in terms of plans, or sub-capabilities and messages between them. Figure~\ref{fig:dealing-cap} provides the capabilities for the dealer agent, Figure~\ref{fig:notary-cap} for the notary agent, Figure~\ref{fig:gatekeeper-cap} for the gatekeeper agent and Figure~\ref{fig:non-player-cap} for the non-player character agent,
271
+
The capability overview diagram allows to specify the internals of a capability in terms of plans, or sub-capabilities and messages between them for each agent. Figure~\ref{fig:dealing-cap} provides the capabilities for the dealer agent, Figure~\ref{fig:notary-cap} for the notary agent, Figure~\ref{fig:gatekeeper-cap} for the gatekeeper agent and Figure~\ref{fig:non-player-cap} for the non-player character agent,
256
272
257
273
\begin{figure}[htp]
274
+
\centering
258
275
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/dealing_capability_overview_diagram.png}
259
-
\label{fig:dealer-cap}
276
+
\label{fig:dealing-cap}
260
277
\caption{Capability overview diagram for capabilities of the dealer agent}
261
278
\end{figure}
262
279
\begin{figure}[htp]
263
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/turn_selection_capability_overview_diagram.png}\\
264
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/end_the_game_capability_overview_diagram.png}\\
265
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/start_dealing_capability_overview_diagram.png}\\
266
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/control_bidding_capability_overview_diagram.png}\\
267
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/count_points_capability_overview_diagram.png}
280
+
\centering
281
+
\subfloat[Turn selection]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/turn_selection_capability_overview_diagram.png}}
282
+
\subfloat[End the game]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/end_the_game_capability_overview_diagram.png}}\\
283
+
\subfloat[Start dealing]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/start_dealing_capability_overview_diagram.png}}
284
+
\subfloat[Control bidding]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/control_bidding_capability_overview_diagram.png}}\\
285
+
\subfloat[Count points]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/count_points_capability_overview_diagram.png}}
268
286
\label{fig:notary-cap}
269
287
\caption{Capability overview diagram for capabilities of the notary agent}
270
288
\end{figure}
271
289
\begin{figure}[htp]
272
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/release_player_capability_overview_diagram.png}\\
273
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_players_capability_overview_diagram.png}
274
-
\label{fig:notary-cap}
290
+
\centering
291
+
\subfloat[Release player]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/release_player_capability_overview_diagram.png}}
292
+
\subfloat[Join players]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_players_capability_overview_diagram.png}}
293
+
\label{fig:gatekeeper-cap}
275
294
\caption{Capability overview diagram for capabilities of the gatekeeper agent}
276
295
\end{figure}
277
296
\begin{figure}[htp]
278
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/receive_a_hand_capability_overview_diagram.png}\\
279
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/bidding_capability_overview_diagram.png}\\
280
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/declare_briscola_capability_overview_diagram.png}\\
281
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/playing_capability_overview_diagram.png}\\
282
-
\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_to_game_capability_overview_diagram.png}
297
+
\centering
298
+
\subfloat[Receive hand]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/receive_a_hand_capability_overview_diagram.png}}
299
+
\subfloat[Bidding]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/bidding_capability_overview_diagram.png}}\\
300
+
\subfloat[Playing]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/playing_capability_overview_diagram.png}}\\
301
+
\subfloat[Declare briscola]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/declare_briscola_capability_overview_diagram.png}}
302
+
\subfloat[Join the game]{\includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_to_game_capability_overview_diagram.png}}
283
303
\label{fig:non-player-cap}
284
304
\caption{Capability overview diagram for capabilities of the non-player character agent}
285
305
\end{figure}
286
306
287
307
\section{Prototype}\label{sec:proto}
288
308
289
-
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.
290
-
The prototype can be logically separated in two parts: firstly the environment in which the agents interact, and secondly the agents themselves.
309
+
The prototype was built according the design decisions 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.
310
+
The development of the prototype can be logically separated in two parts: firstly the environment in which the agents interact, and secondly the agents themselves.
291
311
292
-
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.
312
+
Environments in 2APL, as mentioned in the previos paper, 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 monitoring visually 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 with a GUI that 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 is provided 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. Teams are highlighted in different colors, black and blue.
293
313
294
314
\begin{figure}[htp]
315
+
\centering
295
316
\includegraphics[keepaspectratio,scale=0.3]{fig/gui1.png}
296
317
\label{fig:gui1}
297
318
\caption{Screenshot from the graphical user interface}
298
319
\end{figure}
299
320
300
321
%The agents were designed separately using prolog, and saved in separate files depending on the strategy they were programmed to have.
301
-
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).
322
+
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.
323
+
%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).
302
324
303
-
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.
325
+
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.
304
326
305
-
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.
327
+
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 for now.
306
328
307
329
\section{Conclusion}\label{sec:concl}
308
330
309
-
The general feeling after implementing the Briscola Chiamata game into the 2APL system is both good and bad. I will start with the positive aspects.
331
+
The general feeling after implementing the Briscola Chiamata game into the 2APL system is both good and bad. Let start with the positive aspects.
310
332
311
333
Having a declarative programming when developing agents certainly gives the designer a certain level of confidence that you would not have with other languages. You can focus specifically on ``what'' you want from 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.
312
334
313
-
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.
335
+
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 this kind of openness is a helpful and important feature.
314
336
315
-
The negative aspects of 2APL are few, but certainly relevant. Firstly it is clearly a tool designed primarily for research and not for industry development. The documentation for 2APL is still relatively vague and requires some updating, while the examples given are few and sadly not fully detailed. The environment and the agents we built ware 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 implementing a fully operational high scale piece of software would be made harder due to the poor support is worth mentioning).
337
+
The negative aspects of 2APL are few, but certainly relevant. Firstly it is clearly a tool designed primarily for research and not for industry development. The documentation for 2APL is still relatively vague and requires some updating, while the examples given are few and sadly not fully detailed. The environment and the agents we built were done mostly by scanning the code of the blockworld example and thus we lacked the true ability to implement a full application (this was never our intention, but knowing that implementing a fully operational high scale piece of software would be made harder due to the poor support is worth mentioning).
316
338
317
-
Even though declarative programming does give us a very powerful logic system, it does lack to provide agents with the ability to compute things on their own (in its current state the designer is forced to have the environment calculate it for the agent, instead of allowing the agent to encapsulate the calculation method in its own code). 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.
339
+
Even though declarative programming does give us a very powerful logic system, 2APL does lack to provide agents with the capability to compute things on their own. In its current state the designer is forced to have the environment calculate it for the agent, instead of allowing the agent to encapsulate the calculation method in its own code. 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.
318
340
319
341
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.
320
342