CS470/570  Artificial Intelligence

Program #4: Life in the Game...
(a.k.a., Implementing Adversarial Search)

Overview:  Description: oggle.jpg

It's time to have some fun! And, of course, to get some more hands-on experience with applied AI techniques. As you've noticed from the past programming tasks, there's a huge difference between talking about something theoretically in lecture and implementing a real piece of "smart" software based on the concept! And yet it's creating a clever piece of software that AI is all about...

For our final project this year, we will divide the class up into teams that will each create an implementation of a simple board game called Halma. For the final project, each team will have to present their implementation as a programming deliverable, complete with write-up, just as usual. The fun twist will be that we'll actually have a tournament at the end, where teams will run their Halma players head-to-head, with strict per-turn time limits, to see who has the smartest program. Of course, appropriate rewards will be given to the winner, as outlined below.

Let the games begin!

The Problem:

Because our main aim is to focus on the concepts of adversarial search and building *some* sort of smart game player, we want to choose a game that is relatively simple: simple board, simple rules, simple pieces, and simple piece movement. This will make encoding the basic foundations straightforward and will let teams focus on fine-tuning their gaming engines to make them as clever as possible. The simple board game Halma meets these criteria perfectly: the board is a simple square, there is only one kind of game piece, and movement rules are the same for all pieces. And yet it should be complex enough to create a reasonable-sized search space deep enough to reward finely-tuned implementations.

You can read all about Halma on the wiki page: https://en.wikipedia.org/wiki/Halma . It's basically a game that was invented at by a surgeon at Harvard Medical School in the late1800s, and has the distinction of being "the only truly American board game". It is essentially a simplified version of Chinese Checkers, a better-known update developed later on.

The concept is very simple: you have a square board and play diagonally, from corner to corner. Each player starts with some pieces in their corner known as their camp (or also yard), and the goal is to get all of your pieces into the other person's camp. The main points of the rules we'll observe are:

Although the Halma challenge is fairly simple as far as games go, it will still take some substantial time and effort to get all the little bits programmed and working right. Thus, we will divide up into teams of 2-3 persons for this challenge. To help people out a bit with their planning and division of labor, we'll outline the programming task into distinct overall tasks, and we'll have some "proof-of-progress" milestones along the way.

The Assignment:

Your task, as indicated above, is to work in self-selected teams of 2-3 to create a correct and (hopefully!) skilled Halma playing agent. The agent will provide a graphical view of the game board, as well as a basic two-player turn-taking interface. Here is the basic use case:

  1. You open a terminal window on the gaming machine and invoke python on your game program, providing appropriate command-line parameters:
  2. A window with the graphical representation of the board pops up, with sides marked as Human and Computer, depending on who's playing what color. Like a chess board, the board is labeled with letters ('a' though 'h' ; or j or p, depending on board size) along the bottom (horizontal) edge, and numbers (1 through 8; or 10 or 16, depending on board size) along the vertical edge. This coordinate system is used to refer to board locations. The players' camps are in the top-left and bottom-right corners and, for the sake of uniformity for everyone, let's say that RED is always shown in the top-left, as on the graphic shown here.
  3. Status output: There is a "status bar" above the board; this is just a text area where you can display messages from your program to show what's going on.
  4. Move input. Here you can choose what to provide. Basic: there is a "move entry" text area below the board. This appears/activates when it's the human's turn to enter a move. GUI I/O (extra points): You use clicking to move pieces, e.g., click the piece you wanna move, then click the place to move it to.
  5. You start the game, and play proceeds by taking turns.
  6. When a player wins, the game ends, which is clearly announced in a dialog that also shows (a) number of move-cycles made (b) the final score for each player. The score is the number of pieces in the goal camp, plus (1/d) for each piece outside the camp, where d is the SLD distance between that piece and being somewhere in the home camp. This helps give credit for close games and almost winning.

Timeline and organization:

To help teams organize and to make sure everyone contributes their share of effort, we will divide this task up into a couple of phases, each of which has a list of things to get done. The idea is that these smaller tasks will be assigned to individuals on the team, who are then responsible for getting them done. Of course, individual teams can choose to slice, redistribute, team up on, and otherwise organize tasks within their team as they see fit, but some clear accounting of who did what must be produced at the end. Here are the phases:

Basics Phase: Manual game playing framework, just to get the framework up and running.

This creates the basic game playing framework that allows two humans to play, but is missing an intelligent computer player. Has roughly these main pieces:

Milestone: when done with the basics stage, you should have a functioning game management system for two *human* players: It presents the game and then asks each player in turn for their move, moving pieces accordingly, reporting illegal moves, and reporting wins and scores.

Brains Phase: Creating your Halma agent

Now add a "computer player" by creating a smart Halma playing agent. Assuming that you have the basics in place, including a well-functioning moves generator, this part should be fairly straightforward. The main pieces are:

Just getting your player up and playing legal Halma is only the first step, of course. If you want to WIN the tournament, you'll want to leave plenty of time for refining and fine-tuning your player. Your basic goal here would be to streamline every aspect of the code related to exploring downward in the game tree so that you can fully search as many plies as possible within the time limit. This might mean streamlining often-called functions like the move generator and utility function, but perhaps also exploring other more efficient/compact board representations.

Ultimately, you need to stay within the time limit, so you'll want to test enough to know how long it takes your program, maximally, to search one ply, two plies, three plies, etc etc. That way, when the game starts and the time limit is given, you can tell your program to search to some ply that you *know* is well within that limit, and return a move...then use any remaining time to have it try to tackle the next ply. If time runs out, you can return the move you have; if you can finish another ply, you have an even better move to return!

The Tournament. Finding out who has the most artificial intelligence chops...

This project is the Final Project for the course, and thus is due at the designated time for the final exam. During this time, we will hold a tournament. We can negotiate some details as the time approaches, but the basic plan is to meet in the classroom, establish a playoff bracket, and have a series of head-to-head matches to determine who is the Halma champion. It will go like this:

Dr. D will act as referree, and will be circulating around, scoring the different programs as play progresses. The final round will be played on the class video screens, and bets will be taken!

There are always small details and questions that will arise that are not addressed here, but we can resolve these quickly as we go along. Here are rules for a few detailed situations that have come up in the past:

 

Scoring for this project

Scoring for this project will be similar to that for previous project (effort invested, performance on tests/tournament, quality of code), but adapted for teams and the tournament at end. There are three basic deliverables for this project:

  1. Your hardcopy packet for Phase 1, including write-ups and demos.
  2. Your hardcopy packet for Phase 2, including write-ups and demos.
  3. The tournament, which evaluates the final functional value of your effort.

The hardcopy deliverables will describe the nature and extent of your implementation, including exactly who worked on what parts of the product on each team. The tournament provides the proof of what you state in your write-ups; it's where the rubber hits the road.

The detailed scoring will, of course, be left up to your professor, but the basic outline goes like this:

Project Deadlines and Deliverables:

As outlined above, the project is divided into two phases to help make sure that teams are moving along, and stay on track to produce a good product on time at the final. Each deliverable is a professionally formatted hardcopy; the details and deadlines are as follows: