Closed farhanrahman closed 12 years ago
Ok, I have spent some time today thinking about this issue and we ended up with a solution that the monitor can actually have access to all the countries and can therefore call their public functions.
It gets the access when the countries register for the service. They are then stored in the list of REFERENCES of the countries, so every function we call is executed on the actual instance of the country, not the copy of it.
The biggest advantage of this solution is that it is can be implemented very easily.
There are though several problems It is not safe (e.g. countries can actually access other countries by having the access to the monitor) It is not using Presage primitives
To be honest I am not a big fan of how Presage wants us to implement things (I think it overcomplicates things in different places) and we can use different ways if it makes the implementation easier. Also, countries can cheat, but cheating is something that can happen in the real world. We are a team and no one would implement a function that changes makes the other country e.g. pay the monitoring tax every year as this would destroy the whole game. I also don't expect any hackers to attack the game, so we should stick with the solution of keeping the reference to each country.
Any other opinions?
Does this not fall into the area in which we force agents to update themselves from the shared state using functions built into the AbstractCountry version of execute, which every extension of AbstractCountry is forced to run?
eg. We write a function within the AbstractCountry that checks the shared the space for whether it should be sanctioned. If it is, it deducts the correct amount of cash/whatever. This is similar to how we force agents to pay a tax at a particular time.
Do you then suggest that we add to the shared state a map CountryID -> boolean determining if the country should be sanctioned? Then the monitoring body updates the shared state by changing the boolean value accordingly and then the country queries the shared state to see if it should pay sanctions. If it has to, its internal function decides what form of sanction should be applied. This is a solution that makes o proper use of Presage Service, but it is a really weird thing to implement. Are we sure that the list of countries that should be sanctioned should be in a shared space? This way, each country can see which other countries were sanctioned, is it realistic? Can you tell me all the advantages of using this method that would reward us for the effort of implementing it this way?
That sounds like a relatively straight forward way of doing things, and ties in nicely to how other actions are performed.
Just to clarify, although it will be an internal function, if written within AbstractCountry, it will be performed the same for all countries.
Being able to see which other countries have been sanctioned seems to kills two birds with one stone, as we were initially discussing goodwill lists and such, which can be generated by querying the SharedSpace appropriately.
In terms of effort of implementation, I'd like to hear the input of someone who has implemented something similar.
@jjonnnyy would you help us in the discussion here?
From what I read about multi agent systems (I could be wrong) is that the simple structure is that an agent percepts change to the environment and acts upon the environment. Now the way presage is built, it uses 'services' to pretty much access the environment whether it be accessing directly or leaving it to action handlers or actions (agents not caring about the services). I think we are mis-using the services in this case, first of all because I think services are sort of inactive things. They aren't supposed to directly interact with the agent. Take for example 'facebook'. Facebook is an environment where we upload our data that we want to share. How we do it is through various services (internet, internet browser, phone and so on). These things aren't supposed to tell these agents what to do. Again guys I could be wrong about this...its just my opinion.
We can choose to use this but this is indeed an easier solution to our problem which immediately justifies the use of this with the time that we have. However its kind of hacky as we are directly using the list of participants and have access to everyone's function and can pretty much alter everything and I think (again could be wrong) that this is not a property of the multi agent system. I think we should consult Sam Macbeth about this issue.
I guess that Sam Macbeth is going to say exactly what you have said.
The problem here is that our solution is already implemented (I think Stuart has even tested that in a simulation) and ready to work. I know that it is against the multi-agent systems strategy, but we have a very limited time for implementation and it seems like the option that used services would take much more time (e.g. to create actions, action handlers).
As I can see however, most of you would prefer to have it implemented as a real multi-agent system service. I can work on that, but it can take me some time to get into those labyrinths of Presage again.
I agree with you Adam, this is something that can be looked at a later point (if we have some time). For now since Stuart has got it working, its best to leave it as it is as a lot of things have been written already.
I was looking into the Monitor service. There is a particular problem in declaring Monitor as a service. Essentially you can register a service as a global service i.e. Actions or ActionHandlers can use them or you can register them as ParticipantServices. Either way, services are used for reading or writing shared states in the environment.
The monitoring function is basically determining which agent to monitor and put sanctions on agents who cheated. The only way a monitor can provide sanction (in an unhacky way!) is through protocols.
Do you guys think we should change the monitor to an Agent instead of an Environment Servie?