The 16th Edition of the Multi-Agent Programming Contest - The GOAL-DTU Team

Abstract

We provide an overview of the GOAL-DTU system for the Multi-Agent Programming Contest, including the overall strategy and how the system is designed to apply this strategy. Our agents are implemented using the GOAL programming language. We evaluate the performance of our agents in the contest and, finally, we discuss how to improve the system based on an analysis of its strengths and weaknesses.

A Team Overview: Short Answers

1.1 A.1 Participants and Their Background

• Who is part of your team?

  This year, 3 people were involved: Jørgen Villadsen (PhD), Jonas Weile (MSc student) and during the contest days also Markus Fridlev Schlenzig (BSc student). For earlier iterations of the code that we have built upon, also Alexander Birch Jensen and Erik Kristian Gylling have been involved.

• What was your motivation to participate in the contest?

  To study multi-agent systems in a realistic, but simulated, environment and to enhance our knowledge of the GOAL agent programming language.

• What is the history of your group? (course project, thesis, $\ldots$)

  Our team name is GOAL-DTU. We participated in the contest in 2009 and 2010 as the Jason-DTU team, in 2011 and 2012 as the Python-DTU team, in 2013 and 2014 as the GOAL-DTU team, in 2015/2016 as the Python-DTU team, in 2017 and 2018 as the Jason-DTU team, and in 2019 and 2020/2021 as the GOAL-DTU team. We are affiliated with the Algorithms, Logic and Graphs section at DTU Compute, Department of Applied Mathematics and Computer Science, Technical University of Denmark (DTU). DTU Compute is located in the greater Copenhagen area. The main contact is associate professor Jørgen Villadsen, email: jovi@dtu.dk

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

  We are responsible for the Artificial Intelligence and Algorithms study line of the MSc in Computer Science and Engineering programme.

1.2 A.2 Statistics

• Did you start your agent team from scratch, or did you build on existing agents (from yourself or another previous participant)?

  As our starting point, we used the code from the competition last year—which in turn built upon the competition in 2020.

• How much time did you invest in the contest (for programming, organising your group, other)?

  We have spent approximately 60 h to further develop the code from the previous iteration.

• How was the time (roughly) distributed over the months before the contest?

  Most of the time was spent in August leading up to the qualification. After qualifying, no further improvements were made.

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

  We have about 2000 lines of code.

1.3 A.3 Technology and Techniques

Did you use any of these agent technology/AOSE methods or tools? What were your experiences?

• Agent programming languages and/or frameworks?

  We used GOAL which is a quite easy and intuitive agent programming language.

• Methodologies (e.g. Prometheus)?

  No.

• Notation (e.g. Agent UML)?

  No.

• Coordination mechanisms (e.g. protocols, games, ...)?

  No.

• Other (methods/concepts/tools)?

  We used the Eclipse IDE for programming (it has a GOAL add-on).

What hardware did you use during the contest? We used a laptop.

1.4 A.4 Agent System Details

• Would you say your system is decentralised? Why?

  The team communicates via messages and channels to share information and agree on plans. The approach is mostly decentralized, but planning tasks are currently delegated to a single master agent.

• Do your agents use the following features: Planning, Learning, Organisations, Norms? If so, please elaborate briefly.

  The agents use planning to choose the tasks to pursue. A single agent is chosen to do the planning, but this agent relies on input from all other agents, and the planning agent is chosen dynamically at run time. The planning agent will search through assignment combinations and choose the most promising.

• How do your agents cooperate?

  The agents reactively decide on their actions based on the current percepts, their beliefs and their goals. They use predetermined rules and actions.

• Can your agents change their general behaviour during run time? If so, what triggers the changes?

  An agent will change its behaviour when it is chosen to take part in solving a task.

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

  We chose not to make changes during the contest.

• How did you go about debugging your system? What kinds of measures could improve your debugging experience?

  We used log files to record the agents belief base and percepts.

• During the contest, you were not allowed to watch the matches. How did you track what was going on? Was it helpful?

  We only did basic logging to the console.

• Did you invest time in making your agents more robust/fault-tolerant? How?

  As evident from the competition results, we did not spend enough time on this aspect.

1.5 A.5 Scenario and Strategy

• How would you describe your intended agent behaviour? Did the actual behaviour deviate from that?

  First, to explore and have our agents find other agents, goal-zones and dispensers. Once most agents have connected, they collectively decide on a master agent to do planning. Once this agent has been found, it will continuously inquire the other agents about their available resources and try to create task plans. The task plan is sent to all agents involved in the plan, and these will try to solve it as efficiently as possible.

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

  We defined the overall strategy. The task-plans are created autonomously. We would have liked more flexibility for the agents to evaluate their strategy and correct this strategy as needed.

• Did you implement any strategy that tries to interfere with your opponents?

  We worked on some clearing strategies to defend goal cells, and to scare off opponents. However, they seemingly did more harm than good at the competition.

• How do your agents coordinate assembling and delivering a structure for a task?

  The planning agent creates a structured plan describing which agent should deliver what blocks, based on the input it receives from other agents. All agents involved in delivering a task then continuously check the plan to see if it remains feasible, updating the plan if necessary.

• Which aspect(s) of the scenario did you find particularly challenging?

  The map was made even more dynamic than preceding years, which was definitely a challenge.

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

  If the contest was a week from now, we would mainly focus on bug fixing and thorough testing. If we had a whole year, we would work on changing the way we solve tasks and do planning—we would further decentralize it, removing most of the responsibility of the planning agent, and make the assembling of blocks more dynamic. Also, we should make better use of agents not partaking in solving tasks, as well as improving defensive strategies

• What can be improved regarding the scenario for next year? What would you remove? What would you add?

  We suggest to execute the agents on the same infrastructure by the organisers and then it would be interesting to decrease the time available for the agents to decide on their actions.

1.6 A.6 And the Moral of it is ...

• What did you learn from participating in the contest?

  We learned a lot about using GOAL to write multi-agent programs. We were reminded of the care it takes to develop and test in multi-agent environments.

• What advice would you give to yourself before the contest/another team wanting to participate in the next?

  Start early, because unexpected problems will occur. Have a clear testing strategy. The coordination between agents is working quite well and the A* path finding helps agents to move directly. Agents could be more flexible in helping each other and prioritizing other agents’ tasks over their own when it is better for the team.

• Where did you benefit from your chosen programming language, methodology, tools, and algorithms?

  GOAL has built-in functionality that allows agents to communicate with one another and it has a predefined agent-cycle that is suitable for the belief-desire-intention model. A* was used by the agents to determine movement actions for short distances.

• Which problems did you encounter because of your chosen technologies?

  Writing thorough tests for GOAL code can be challenging,

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

  Some unexpected problems (unrelated to the contest) ended up costing us a team member, and another team member had less time to work on the project than anticipated. This led to a large loss of potential time.

1.7 A.7 Looking into the Future

• Did the warm-up match help improve your team of agents? How useful do you think it is?

  It was not really useful due to the lack of time for improvements.

• What are your thoughts on changing how the contest is run, so that the participants’ agents are executed on the same infrastructure by the organisers? What do you see as positive or negative about this approach?

  Yes, it would be great if the agents are executed on the same infrastructure.

• Do you think a match containing more than two teams should be mandatory?

  Maybe—perhaps if the agents are executed on the same infrastructure.

• What else can be improved regarding the MAPC for next year?

  We would prefer more or less the same scenario.