advances with documentation · mgabarda.com/2apl-upc-project@9b2a3ab

+87 -27

docs/briscola_chiamata/bc-doc.tex

··· 75 75 76 76 Here follows a brief description of each of them: 77 77 \begin{itemize} 78 - \item 79 - "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. 80 - \item 81 - Dealing scenario is in charge of choosing the dealer, shuffle the deck and deal cards to all subscribed the players in the system. 82 - \item 83 - 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. 84 - \item 85 - "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. 86 - \item 87 - "End of the game" scenario is in charge of declaring the winner team, update the score of each player according to the scoring rules and release the player from the system. 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. 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 + \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 + \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. 82 + \item ``End of the game'' scenario is in charge of declaring the winner team, update the score of each player according to the scoring rules and release the player from the system. 88 83 \end{itemize} 89 84 90 85 Finally, percepts and actions in the system are summarized in Table~\ref{table:inout}. ··· 165 160 166 161 \subsection{Agent-Role Grouping Diagram} 167 162 168 - 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. 163 + 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. The ``dealer'' agent type represents the dealer that is in charge of dealing cards. The ``gatekeeper'' agent type represents the agent that let the players come in and out the system. The ``non-player charcter'' agent types represents the actual players in the system. Finally the ``notary'' agent type represents the agent in charge of controlling the game. Figure~\ref{fig:agentrole} provides the agent-role grouping diagram for our game. 169 164 170 165 \begin{figure}[htp] 171 166 \includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/aget-role_grouping.png} 172 - \label{fig:sysroles} 167 + \label{fig:agentrole} 173 168 \caption{Agent-role grouping diagram} 174 169 \end{figure} 175 170 176 171 \subsection{Agent Acquaintance Diagram} 177 172 178 - In the agent acquaintance diagram you can see all agents within the system and which agents interact. 173 + 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}. 179 174 180 175 \begin{figure}[htp] 181 176 \includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/agent_acquaintance.png} 182 - \label{fig:sysroles} 177 + \label{fig:agentacq} 183 178 \caption{Agent acquaintance diagram} 184 179 \end{figure} 185 180 186 - \subsection{System overview Diagram} 181 + \subsection{System Overview Diagram} 187 182 188 - In the system overview diagram you can see all agents in the system, along with their interface and interactions. This diagram is the central diagram of the entire system design. 183 + 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}. 189 184 190 185 \begin{figure}[htp] 191 186 \includegraphics[keepaspectratio,scale=0.45]{pdt/images/architectural_design/system_overview.png} 192 - \label{fig:sysroles} 187 + \label{fig:sysovervw} 193 188 \caption{System overview diagram} 194 189 \end{figure} 195 190 ··· 198 193 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. 199 194 200 195 \subsection{Agent Overview Diagram} 201 - The agent overview diagram shows the internals of an agent. There is one agent overview diagram for every agent in the system. In the detailed design, much finer details of the system are established. The messages used to communicate between the agents are decided upon. If the roles within an agent grow very large, they are grouped into capabilities. As in the system overview diagram entities can be inserted or removed and edges can be reated or deleted. 196 + 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}. 202 197 203 - \subsection{Capability Overview Diagram} 204 - In the capability overview diagram you can see the direct internal of a capability. This diagram allows you to specify the internals of a capability in terms of plans, or sub-capabilities and messages between them. Data internal to the capability can also be specified. 198 + \begin{figure}[htp] 199 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/dealer_overview_diagram.png} 200 + \label{fig:dealer} 201 + \caption{Agent overview diagram for the dealer agent} 202 + \end{figure} 203 + \begin{figure}[htp] 204 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/notary_overview_diagram.png} 205 + \label{fig:notary} 206 + \caption{Agent overview diagram for the notary agent} 207 + \end{figure} 208 + \begin{figure}[htp] 209 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/gatekeeper_overview_diagram.png} 210 + \label{fig:gatekeeper} 211 + \caption{Agent overview diagram for the gatekeeper agent} 212 + \end{figure} 213 + \begin{figure}[htp] 214 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/non-player_character_overview_diagram.png} 215 + \label{fig:nonplay-char} 216 + \caption{Agent overview diagram for the non-player character agent} 217 + \end{figure} 218 + 205 219 206 - \section{Prototype}\label{sec:proto} 220 + \subsection{Capability Overview Diagram} 221 + 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, 207 222 208 - Description. Excerpt from the code. 223 + \begin{figure}[htp] 224 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/dealing_capability_overview_diagram.png} 225 + \label{fig:dealer-cap} 226 + \caption{Capability overview diagram for capabilities of the dealer agent} 227 + \end{figure} 228 + \begin{figure}[htp] 229 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/turn_selection_capability_overview_diagram.png} 230 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/end_the_game_capability_overview_diagram.png} 231 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/start_dealing_capability_overview_diagram.png} 232 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/control_bidding_capability_overview_diagram.png} 233 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/count_points_capability_overview_diagram.png} 234 + \label{fig:notary-cap} 235 + \caption{Capability overview diagram for capabilities of the notary agent} 236 + \end{figure} 237 + \begin{figure}[htp] 238 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/release_player_capability_overview_diagram.png} 239 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_players_capability_overview_diagram.png} 240 + \label{fig:notary-cap} 241 + \caption{Capability overview diagram for capabilities of the gatekeeper agent} 242 + \end{figure} 243 + \begin{figure}[htp] 244 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/receive_a_hand_capability_overview_diagram.png} 245 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/bidding_capability_overview_diagram.png} 246 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/declare_briscola_capability_overview_diagram.png} 247 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/playing_capability_overview_diagram.png} 248 + \includegraphics[keepaspectratio,scale=0.45]{pdt/images/detailed_design/join_to_game_capability_overview_diagram.png} 249 + \label{fig:non-player-cap} 250 + \caption{Capability overview diagram for capabilities of the non-player character agent} 251 + \end{figure} 209 252 210 - \section{Conclusion}\label{sec:concl} 253 + \section{Prototype}\label{sec:proto} 211 254 212 - What's wrong with 2APL? 255 + - prototipe developed following the Prometheus design 256 + - easy way to implement design solutions into 2APL agents 257 + - tring to use the maximun features and bondaries of 2APL 258 + - environment done in java, with gui to show the game (but not actually necessary) 259 + - posibility of add an human player in the future 260 + - other agents (that imports player.2apl) can add own strategies 261 + - limited use of Prolog in the belief base. probaly it can be improve if agents could add extra prolog libraries 262 + - bad parser of 2APL language, the syntactical error are not clear at all 263 + - add screenshot and sample of code (you dedice where to put, then ill add em) 213 264 214 - No security mechanisms, No documentation like a manual or of examples (only short example provided with the platform). Not all the constructs available are documented (e.g. random() or print()) 215 265 216 - If an agent requires an action not related with changing its mental state, it has to be done through the environment. It would be nice to have agents in which part of its executing plan will consist of running some classification algorithm or some numerical method which is only owned by the agent and so it could be encapsulated in its program. 266 + \section{Conclusion}\label{sec:concl} 217 267 218 - The platform is well done, but it's still a tool for research 268 + - declarative way of programming its better to develop agents, you only have to care about "what" the agents have to do, and not "how" (conceptual division) 269 + - problems if you aren't confortable with declarative languages but it's ok the price to pay 270 + - the framework can be improved, adding more debug features (The platform is well done, but it's still a tool for research) 271 + - in global overview, we can develop agents solutions fast 272 + - we can connect with other JADE platform, and this is good 273 + - bad parser of 2APL language, the syntactical error are not clear at all 274 + - lib can be added (e.g. No security mechanisms) 275 + - No documentation like a manual or of examples (only short example provided with the platform). 276 + - Not all the constructs available are documented (e.g. random() or print()) 277 + - If an agent requires an action not related with changing its mental state, it has to be done through the environment. It would be nice to have agents in which part of its executing plan will consist of running some classification algorithm or some numerical method which is only owned by the agent and so it could be encapsulated in its program. 278 + - Anybody can write its onw player agent! 219 279 220 280 \section{Bibliography} 221 281 \nocite{*}

docs/briscola_chiamata/pdt/images/detailed_design/bidding_capability_overview_diagram.png