Knowledge and Reasoning / Intelligent Systems Techniques

Introduction

Instructions for lab sessions

Assessment is based on one programming assignment and an unseen exam. Most of the syllabus material is in the online lecture notes (below), but note-taking and additional reading is strongly advised.

The first meeting for the course will be the first lecture in week 1.

The first lab will be your scheduled lab session in week 2.

Lectures

Assessment

The programming assignment is due Thursday of week 8 (see Sussex Direct closer to the time for final arrangements). The task is to construct a checkers (draughts) game in Java. The program should present an interactive draughts board that allows pieces to be moved around as per the rules of the game. (See http://www.indepthinfo.com/checkers/play.shtml if you're unsure what these are.) It should be able to produce legal gameplay at different levels of difficulty, making use of minimax and alpha-beta pruning, as explained in the lectures in the first half of the term.

You can start work on this assignment as soon as you like but bear in mind that the lectures on minimax and alpha-beta pruning are in week 5. Normally it will make sense to commence work around weeks 4-5, unless you get well ahead with the material. This gives you a clear three weeks to complete.

There are 25, equally-weighted assessment criteria. In developing your program, you should try to satisfy as many of these as you can.

1. State representation of some sort.
2. Valid state representation.
3. Successfor function of some sort.
4. Valid successor function.
5. Use of successor function for move selection.
6. Board display of some sort.
7. Valid board display.
8. Valid, dynamic display.
9. Elements of minimax search used
10. Valid minimax search used
11. Interactive board display.
12. Pieces disappear on being taken.
13. Drag-and-drop board display.
14. Turn-taking gameplay enforced.
15. System-generated moves (i.e., active AI)
16. System-generated valid moves (i.e., valid AI)
17. Turn-taking gameplay.
18. System rejects invalid user moves.
19. System able to use multi-step moves
20. Step-at-a-time display of multi-step moves
21. System uses alpha-beta pruning
22. Variable level of AI (ie. a difficulty slider)
23. System accessible from web page (e.g., applet)
24. System offers tutorial guidance
25. System wins games reliably

I use the lab sessions of weeks 9 and 10 to assess your work. So you should be ready from end of week 8 to give me a short (3-4 minute) demo, at which I will note the criteria that you're met. (If it's not possible for me to see all the demos in lab time, I'll arrange extra sessions as needed.) The demo is mainly for assessment. However, students in the same lab session are invited to watch demos too.

As well as providing the demo, you should submit the text of your code (all the class files) electronically through Sussex Direct. If you submit a jar file, make sure it includes all the source files. The source code you submit online will be used to resolve any ambiguities concerning criteria that have and have not been met. Note the code you submit must be the code used for your demo. All university rules on plagiarism apply.

Extra feedback

Course texts

Russell and Norvig, `Artificial Intelligence: A Modern Approach.' (There are many copies in the main library and one in the department library.)

Also of interest is this AI-in-Java text:

Bigus and Bigus, `Constructing Intelligent Agents in Java.' (6 copies in the library including one in reserve section. I also hope to arrange for the COGS library to buy a copy.)

For something lighter, try

`Hal's Legacy' edited by David G. Stork. This provides a light-hearted overview of the state-of-the-art in AI.

Programming issues

I don't require you to follow any particular programming genre or style, i.e., it doesn't have to be pure `OOP'. However, you do need to be consistent, and to follow the general principles of good programming. These are as follows.

1. modularity: modular programs are made up from small, independent components (typically methods) that can be tested and debugged in isolation from the rest of the program. Such components get their data via formal input parameters. They only affect the rest of the program via the formal outputs (results) they return. They are effectively `black boxes' which, once validated, can be eliminated from the debugging process. Modular programs make little or no use of class variables for communication information from one part of the program to another. Writing your program in a modular way is a way of pursuring a divide-and-conquer strategy.

2. simplicity: don't introduce additional complications unless there is a genuine need. Don't start experimenting with advanced features of Java (e.g. final variables and inner classes) without good reason. If you find you are writing the same (or almost the same) code more than once, look for a way to eliminate the redundancy. You'll probably need to create a new method or class which can be used in different situations.

3. transparency: choose your variable and method names so as to make the code self-explanatory as far as possible. (This will only be possible if you've made your code modular.) The name of a variable (or method) needs to describe the role being played. Resort to inline comments when you are unable to find a way of making the code tell its own story. But if you do use inline comments, keep them short, and format them so as to minimise disruption to the visual structure of the code. Don't let line-wrap problems obscure indentation.

4. presentation: the program should be presented neatly and clearly, using consistent conventions for use of blank-lines etc. Indentation should be consistently used to show the logical structure of the program, particularly the presence of contingencies (i.e., `if' statements) and loops. Programs should be commented in the standard `javadoc' style but please note that the javadoc listing should NOT be included with your submission.