Programming Project

Pelita is a Pac-Man like game. Two teams each of two bots are placed in a maze with food pellets. The maze is split into two parts, the left one belongs to the team on the left (the blue team), the right one belongs to the team on the right (the red team). When a bot is in its own homezone it is a ghost. A ghost can defend its own food pellets by killing the enemies. When a bot is in its enemy's homezone it is a pac-man and can eat the enemy's food.

Your task as a group is to write a bot implementation. You have to implement the intelligence to navigate your bots successfully through the maze, kill the enemy's pacmen, and eat the enemy's food.

No special previous knowledge about machine learning, artificial intelligence, deep neural networks, [insert your buzzword here], is required! All you need is a bit of Python knowledge and having attended the first three days of ASPP ;)

Fork the group repo:

• group0: https://git.aspp.school/ASPP/group0
• group1: https://git.aspp.school/ASPP/group1
• group2: https://git.aspp.school/ASPP/group2
• group3: https://git.aspp.school/ASPP/group3
• group4: https://git.aspp.school/ASPP/group4

See the documentation directly in the repo!

We want to give you a chance of putting into practice the software development techniques and tools we have been talking about during the school.

We expect you to try out the techniques, and evaluate what is feasible and what not, what helps you being more efficient at writing reliable code, and what feels like a hindrance instead. By doing this in the group we expect you to profit from the experience of other students, and, by explaining to other students your own experiences, to become more aware of what is it that you already master and what is it that you still have to learn.

Write tests for the part of your code which are testable, decide what parts you can test, what parts you should test, what parts you must test, and also what parts can not be tested. Use git and GitHub, use branches or pull-requests: is this going to facilitate your work or is this adding a useless overhead? Feel invited to explore the trade-offs involved!

The idea of the group project is not to write the coolest AI-powered bots! Remember that and don't get carried away by the competition. More about this in the next paragraph.

Some of you will feel the rush of competition, and when working under time pressure may start skipping good coding practices to get “something that works” or “to win”. Others may be annoyed by it, and may feel it is important to stay focused on good practices and don't care much about the result of the competition.

In part, this is the way humans work, so there is not much you can do about it. But it may help to frame the experience in a different way.

Back in the lab you will be also subject to all kinds of pressure. A typical situation is your boss asking for results and not caring about you writing nice, tested and reusable code. You will be often asked to just “deliver”, independent of the standards you set for yourself.

Look at the programming project as a paradigmatic example of a real life situation. How do you work under pressure? How do you handle the trade-off between “just deliver” and “live up to your own standards”? How do you deal with the fact the other people, be it your boss or your team mates, put pressure on you? There is a lot to learn in such a context!

The group setting adds some additional hurdles to the challenge: you will be confronted with group dynamics which go beyond each member's technical skills. Try and have a curious and open attitude towards this experience, even when it becomes frustrating, annoying or even irritating. Everyone makes mistakes: enjoy making your own and helping other discover theirs.

Remember that as a group you can define your own rules. You are responsible as a group for keeping a nice and stimulating atmosphere during your long programming sessions. Talk about how to distribute the work and how to distribute responsibility: these things don't happen on their own by magic! You will be amazed at discovering how many of the things you take for granted are not granted at all for other people. Be open in the group about problems, even and especially about inter-personal problems ;) And, if nothing else helps, come to us and we will help you!

The final tournament is intended as a final party, where you can have fun watching your “product” running around in a maze. It doesn't really matter which group is going to win. Remember: no bot will be harmed in the making of this film ;)

Organizational:

• take some time to discuss how you want to organize and distribute the work
• take some time to discuss about the rules in your group. For example:
  • Are you allowed to be late or leave early?
  • Are you allowed to work alone and putting on your headphones?
  • Are you allowed to work outside of the classroom?
  • Are you allowed to push to main without having a review by another member of the team?
  • [If this were my group, the answer would be No to all questions :)]
• choose persons responsible for certain roles. You need at least:
  • a group speaker, and most probably…
  • … a release manager (the git “pope”)
  • [those two shouldn't be the same person]
• take time, once in a while, to step back and have a look at how the group work is going and to discuss if you need adjustments
• work in pairs

Technical:

• make sure each pair works on different files
• write tests
• everyone should write tests for their own code, don't assign someone specific to “write the tests” for everyone. Testing doesn't work this way!
• do not waste too much time discussing your TEAM_NAME, but choose one before the tournament
• choose a git workflow:
  • if you choose to work with forks and PRs, decide who is going to merge PRs (the release manager)
  • if you choose to work in one repo, use different branches for different pairs (you still need someone responsible for merging the different branches when needed)
• later we will make network bots available which are more advanced than the demo ones, so that you can try your bots against more serious opponents
• do not waste hours debugging Pelita or wondering about exotic cases: ask the tutors, they are there for you and are happy to help!

At the end of the first session:

• Discuss the above points and write down the outcome of that discussion, even just as a list of bullet-points, into a new file called collaboration.md in your group repo and push it, so that the faculty can review it

The tournament is organized in two phases:

1. all-against-all (round-robin). Every team plays once against every other team:
   • 0 points for losing a game
   • 1 point for a draw
   • 2 points for winning a game
   • the maze is randomly chosen for each game among the built-in mazes of normal size (32×16)
   • your team's side (blue/red) is randomly assigned
2. a knockout round (based on the rank from the round-robin):
   • semifinal 1: the 1st team against the 4th
   • semifinal 2: the 2nd team against the 3rd
   • final: the two winners of the semifinals against each other
   • last-chance final: the winner of the final against the 5th team from the round-robin

To start a network game:

  pelita bot.py pelita://pelita.aspp.school

or

 pelita groupN/bot.py pelita://pelita.aspp.school

and follow the instructions on screen. You can also play against one specific network bot by using the bot's URL directly on the command line invocation.

Of course, remember that your bot can also play on the right side, so make sure to test eg. pelita pelita://pelita.aspp.school bot.py as well.)