A Task-Oriented Architecture with Priority Queue for BDI Agents Applied to the Multi Agent Programming Contest Scenario

Abstract

On 2018 we participated of a Multi-Agent Programming Contest, as Akuanduba_UDESC team. We matched upon Agents in the City scenario, with our agents aiming to earn money, fulfilling jobs and missions and also get points through the wells. To accomplish these goals we used a task-oriented architecture with a priorities queue to manage tasks, focusing on developing agents that can choose correctly which tasks they need to perform and change the tasks state to coordinate themselves. We did not reach a good position on the contest, mainly because of a poor strategy for the wells building, but we have saw that all those things we focused on our development returned good results (i.e. the priorities queue and the tasks manager worked successfully).

A Team Overview: Short Answers

1.1 A.1 Participants and Their Background

• What was your motivation to participate in the contest?

  Our professor Schmitz had already joined MAPC before and he wished to introduce the contest into our university. He chosen some students to participate with him allowing us to have a different programming experience.

• What is the history of your group? (course project, thesis, ...)

  Our group is composed by members of a researching project coordinated by professor Schmitz. Until 2017, the project focused on how to use multi-agent systems to coordinate autonomous aerial vehicles to analyse the Auto Vale do Itajaí hydrography. Starting in 2018, we began focusing to MAPC contest and studying the multi-agent language Jason and the framework JaCaMo.

• What is your field of research? Which work therein is related?

  The professor Schmitz has masters and doctorate in multi-agents area and the students began studying multi-agents in early 2018.

1.2 A.2 Development

• How much time did you invest in the contest for programming vs. other tasks (for example organization)?

  We utilized approximately 300 h for the programming, and near by 200 h focusing on other tasks.

• creating vs. optimizing your agents?

  We spent approximately 150 h for the agents creation. The optimizing task demanded more work, requiring approximately 350 h.

• How many lines of code did you produce for your final agent team?

  3093 lines on Jason

  1062 lines on Java

• How many people were involved and to which degree?

  4 undergraduate students and 1 doctor.

• When did you start working on your agents?

  April, 2018.

1.3 A.3 System Details

• How do your agents work together? (coordination, information sharing, ...)

  Our agents were developed on Jason language and JaCaMo framework. The agents communicate themselves and coordinate through messages trading, sending help requests to fulfill tasks. Regarding the agents tasks attribution we utilized a CArtAgO artifact to perform a centralized distribution.

• What are critical components of your team?

  All the agents have a tasks manager, which maintains the integrity of the tasks the agents need to perform.

• Can your agents change their behavior during runtime? If so, what triggers the changes?

  After started, there is not any change on agents behaviour.

• Did you have to make changes to the team (e.g. fix critical bugs) during the contest?

  No, we did not made any change.

• How do you organize your agents? Do you use e.g. hierarchies? Is your organization implicit or explicit?

  We made a separation by roles. A drone agent, for example, accomplish a specific kind of task. There are also some agents who have special jobs, like performing a calculation or deciding who will fulfill a task.

• Is most of your agents’ behavior emergent on an individual or team level?

  The recharge behavior of the agents is on an individual level, because it ignores every call while it is going to recharge. All other tasks were planned on team level.

• If your agents perform some planning, how many steps do they plan ahead?

  Once the agent receives a task it plans through a steps list how the task will be accomplished. The quantity of steps they plan ahead depends of each task. For the agents who have more than one task, each task has its own priority. So, the agent is only reactive by choosing which task it will perform, selecting the one with the highest priority.

• If you have a perceive-think-act cycle, how is it synchronized with the server?

  The artifact EISAccess receives information of the server. Whenever the agent realizes change in the step observable property, the thinking cycle gets triggered.

• How did you go about debugging your system?

  We used console messages.

• Which operating system did you use, and is your team portable to other operating systems?

  We used Windows. Since JaCaMo framework is made upon Java, the system is portable to other operating systems without changes.

• What hardware did you use to run your agent team? (RAM, CPU, disk space, multiple computers, any other notable requirements)

  We used three computers, each one with 16 GB RAM, and processor Intel Core i7-4770 CPU @ 3.40 GHz 3.40 GHz. Each computer was running a part of the agents, and only one was running the CArtAgO environment.

1.4 A.4 Scenario and Strategy

• What is the main strategy of your agent team?

  At the beginning, drone agents scan the map to find out the positions of all the installations (that still can not be seen in map). Meanwhile, other agents begin searching for basic items (items which do not need to be crafted). When items quantity is high enough, the agents begin the composed items crafting (items that can not be gathered in resourceNodes). The agents are responsible by the jobs. Once they realize that all the required items for one job are available on the central storage an agent complete this job. About the wells: an agent was in charge of searching for and destroying enemy wells, while two agents was building new wells.

• How do your agents decide which jobs to complete?

  Once the agents receive a job, they verify to find out if all the items required by the job are available on the central storage. If so, the job is performed, otherwise it is ignored by the agents.

• Do you have different strategies for the different roles?

  Yes, the drones are responsible to initially make a map sweep. A part of the trucks has obligations with the basic items, and a motorcycle has aim to destroy wells. The remaining agents divide themselves into items builders, builder helpers and job delieverers.

• Do your agents form ad-hoc teams to complete a task?

  We separated our agents by agent types performing determined tasks. For example, drones (and only drones) wwew performing the map sweep, trucks (and only trucks) were collecting basic items.

• How do your agents decide when and where to build wells?

  We catched all the points containing installations and the most distant points of the center were used to create the biggest convex polygon. From them we calculated the threshold zone, composed by the map totality less the region of the biggest convex polygon. We used This area to build two wells.

• If your agents accumulated a lot of currency, why did they not spend it immediately?

  Because our strategy was composed by building only two wells so the most part of the money was spent only on upgrades.

1.5 A.5 And the Moral of it is ...

• What did you learn from participating in the contest?

  We learnt the framework JaCaMo, the multi-agents oriented paradigm and mainly analyse and develop a multi-agents system with a strong coordination between agents.

• What are the strong and weak points of your team?

  Our agents were efficient producing items and delivering jobs, but we failed on creating wells task. The strong points of our team were that we had an efficient allocation of tasks to the members of the team. The weak points was that we had minimal knowledge on the utilized language and about the operation of the contest. Communication among the failed sometimes. We also experienced resistance and troubles by using the Version Control System (VCS).

• How viable were your chosen programming language, methodology, tools, and algorithms?

  The JaCaMo framework was chosen exactly because it embraces the development of multi-agents systems. Using the ojalgo library helped us on the optimization tasks. The set of utilized features (JaCaMo, ojalgo, Eclipse) was suitable for the system development.

• Did you encounter new problems during the contest?

  Yes, our agents were optimized for a specific map and failed for others utilized on the contest. We had also troubles with network instability.

• Did playing against other agent teams bring about new insights on your own agents?

  Yes, we noticed our bad exploitation of money for producing wells.

• What would you improve if you wanted to participate in the same contest a week from now (or next year)?

  We would add into our strategy the creation of more wells and optimize our agents battery recharge algorithm for the biggest maps.

• Which aspect of your team cost you the most time?

  Developing the tasks manager. Once it was concluded all the others tasks had a similar time spent (among them).

• Why did your team perform as it did? Why did the other teams perform better/worse than you did?

  Our wells build strategy failed and the other teams reached a better position than ours because they had a more consistent strategy. On the other hand, our strategy was focused on obtaining a lot of items and money. On this point we had an efficient performance.

1.6 A.6 The Future of the MAPC

• What can be improved regarding the contest for next year?

  Optimize the map interface to turn easier viewing the data of each element. For example, the implementation of a field where one may type the name of an agent and automatically selected it.

• What kind of scenario would you like to play next? What kind of features should the new scenario have?

  We have no idea.

• Should the teams be allowed to make changes to their agents during the contest (even based on opponent agent behavior observed in earlier matches)? If yes, should only some changes be legal and which ones (e.g. bugfixes), and how to decide a change’s classification? If no, should we ensure that no changes are made and how?

  We are not in favor of changing the agents after the contest beginning, including bugs.

• Do you have ideas to reduce the impact of unforeseen strategies (e.g., playing a second leg after some time)?

  If an unforeseen strategy causes a loss in the match, then the responsible team loses the match.