Clean up included players

[Debilski]

Other than for testing purposes, the framework itself does not need to include any pre-defined players. Ideally, player.py would only define AbstractPlayer; all other players could live in another, external, namespace.

Additionally, the plan was to remove the BFSPlayer and BasicDefensePlayer completely from the package in order to decrease the possibility of last-minute cheating. The question then is: How to test them such that they are up-to-date with the latest API changes?

[otizonaizit]

I don't see why having some default/demo players in player.py is a problem. And I don't see why we should have an external namespace, if by that you mean that users would have to do

import pelita
import pelitademoplayers

This issue is nonetheless important, because we definitely want to remove BSFPlayer and BasicDefensePlayer and implement instead some less “intelligent” players. If we remove them, we don't need to test them. The new players, if they still live in player.py, are testable without problems, right?

[Debilski]

Well, one idea would be to have a pelita.core with only the framework and everything else outside. All non-abstract players are only ever used by the pelitagame script which isn’t inside the pelita module either. It’s nothing too important but in a way I think it’s cleaner to separate it somehow. Having the pelitagame demo players in separate files instead of inside a huge library file might or might not increase chances for people to actually study the implementation details.

—

Well, surely we’ll need to test the BFSPlayer and the BasicDefensePlayer if we ever want to use them inside a black box. But they’ll only ever be guaranteed to work for one specific pelita release. Shouldn’t be much of a problem, though.

[Debilski]

So, the external players of course get their external testing.

[otizonaizit]

Well, one idea would be to have a pelita.core with only the framework and everything else outside. All non-abstract players are only ever used by the pelitagame script which isn’t inside the pelita module either. It’s nothing too important but in a way I think it’s cleaner to separate it somehow. Having the pelitagame demo players in separate files instead of inside a huge library file might or might not increase chances for people to actually study the implementation details.

I don't think this kind of refactoring is really useful. It breaks old examples, documentations, possibly clients to no real gain: "in a way I think it’s cleaner to separate it somehow" doesn't strike me as a very compelling reason ;)

So again, I think that precious developer time should be instead spent in implementing the dumber players to use in place of BFSPlayer and BasicDefensePlayer. I think there will be a lot to discuss about those, as we don't want them to be so dumb that they are unusable, nor we want them to be as intelligent as they are now.

Creating a private repository on python.g-node.org for storing BFSPlayer and BasicDefensePlayer as well as other players for the students to play against during the programming project is on the other hand a very good idea. Should I do it? What name do you prefer? We already have /groups/schoolfac/players.git but maybe we need to keep it separated from the tutors' players...

[Debilski]

Do you think we could apply for an educational account for ASPP? We could have a private repo then on github for that stuff.

We should definitely have a repository separated from the tutors’ bots for these semi-official no-experiments players.

Yeah, do you have a dumb-down strategy for the included bots? Anything that uses graph search seems to be potentially stronger than anything which doesn’t use it.

[otizonaizit]

Do you think we could apply for an educational account for ASPP? We could have a private repo then on github for that stuff. Why do we need to use github for this? We can have private repos on python.g-node.org. That server is backed up daily and it belongs to us. No need to let our private date go overseas ;)

We should definitely have a repository separated from the tutors’ bots for these semi-official no-experiments players. OK, give me a name for it. What about pelita-players?

Yeah, do you have a dumb-down strategy for the included bots? Anything that uses graph search seems to be potentially stronger than anything which doesn’t use it. Ok, so what about not using graphs and locate the nearest food (in manhattan sense) by just computing the distance between bot and all food pellets? Then, just try to move towards it. Same thing for the defender, changing food for enemy where appropriate? Could it work half-decently?

[Debilski]

Am 16.07.2013 um 10:48 schrieb Tiziano Zito notifications@github.com:

Do you think we could apply for an educational account for ASPP? We could have a private repo then on github for that stuff. Why do we need to use github for this? We can have private repos on python.g-node.org. That server is backed up daily and it belongs to us. No need to let our private date go overseas ;)

Issues, maybe. And automated testing.

We should definitely have a repository separated from the tutors’ bots for these semi-official no-experiments players. OK, give me a name for it. What about pelita-players?

+1

Yeah, do you have a dumb-down strategy for the included bots? Anything that uses graph search seems to be potentially stronger than anything which doesn’t use it. Ok, so what about not using graphs and locate the nearest food (in manhattan sense) by just computing the distance between bot and all food pellets? Then, just try to move towards it. Same thing for the defender, changing food for enemy where appropriate? Could it work half-decently?

Sounds all right to me, but we’ll need to make it a bit smarter else we’ll never be able to move around corners.

[Debilski]

Is that one dumb enough or still too smart? It uses a shortest path strategy to move to a random food.

https://gist.github.com/Debilski/0f83566968acd4e900da

[Debilski]

Ahem, the link to the private repo?