RISK for Java
Project Specification

Networked Risk on the Java Virtual Machine


Motivation

Risk is a board game produced by Parker Brothers, it's objective is to control every country on the globe. Although the game is largely strategic, players battles are governed by the rules of chance. Since rolling dice and moving the counters representing armies is time consuming Risk can take anything up to 24 hours to complete. On a computer the longest game tends to last no longer than an hour.

Over time there have been several releases of computerized Risk. All in some measure have short comings. Listed below are some of the problems I have identified in my preliminary research. Note that these are not faults of all packages but every version of Risk I have seen to date has on of the following problems.

This project exists to address these problems.


Aims and Methods

I have identified six goals for this project. They are shown here in order.

  1. Design a protocol for several clients to communicate with a server
  2. Design the best possible user interface for the client
  3. Design a means for robot processes to communicate with the server
  4. Design and implement the client and server
  5. Implement a library for robots to use
  6. Design and develop some robot players


1. Design a protocol for several clients to communicate with a server

A protocol must exist between the client and server. Clients must be kept up to date with game state, the server must be told of users intentions. Having established the communications between client and server then a protocol can be developed permitting all likely communication. A character based protocol (rather than a Java object based one) would make it easier to permit robots to be developed in other languages.

2. Design the best possible user interface for the client

User interface design is by nature an art rather than a science. To be successful the interface must be easy to learn but not restrictive for more experienced players.

3. Devise a means for robot processes to communicate with the server

It must be easy to create robots. If the client/server protocol is text then much of this aim will have been achieved in the protocol design. This allows programmers to write robots in any language.

4. Design and implement the client and server

The client and server will be developed in parallel as they are inter-dependent. As with all projects good design principles must be adhered to. As things stand I plan to use the Fusion method of object oriented development, largely because I am already familiar with it but also because of it's adaptability. The method is not a rock, more a guideline.

5. Implement a library for robots to use

This library should be written in the main implementation language (Java) to provide a network independent means to communicate with the server and to save state information.

Providing this library is well documented it should provide a model if robot developer wants or needs to use a different language.

6. Design and develop some robot players

Using the above library develop some example robots. This stage must be necessarily vague. In a way this is likely to be in innovative part of the project however an huge amount of development effort must precede the coding of robots. Design and development could be considered independent aims because at this stage of the amount of coding time will be very limited.


The project can be considered fully successful if aims up to and including four have been met. Providing the design is of a sufficiently high standard then future development should follow naturally.

If robots have been developed then the project can be considered very successful. I imagine several breeds of robot. Initial robots will only take a subset of Risk rules into account. Second generation robots will play Risk taking most or all Risk rules into account. Third generation robots would no longer be 'hard coded' but 'learn' how to play. Within the scope of the project, third generation robots should be considered miraculous.


Timetable

Term One

Week 4

Research. Clarify rules of Risk, produce formal list of actions and reactions that can be performed on/by the server.

Week 5

Design. Using above research produce protocol as aim one.

Week 6

Design. Use some object design methodology to produce detailed design for server.

Week 7

Research and design. Examine existing human computer interfaces. Design a new interface. Produce a draft user manual.

Week 8

Design. Use some object design methodology to produce detailed design for client.

Week 9

Design. Using a variation of some design methodology produce detailed design for robot interaction.

Week 10

Slack. Absorb scheduling problems and re-draft as much report as exists at this time

Holiday

Christmas

User Interface development. This is a huge part of the development effort. There is however nothing revolutionary about developing an interface in Java, hence I hope to spend my term time work on more 'important' issues.

Term Two

At this stage this can only be vague

Week 1

Development of client and server.

Week 2

Development of client and server.

Week 3

Development of client and server.

Week 4

Development of client and server.

Week 5

Development of client and server.

Week 6

Development of client and server.

Week 7

Development of robot control library.

Week 8

Design and development of robot players.

Week 9

Design and development of robot players.

Week 10

Design and development of robot players.

Holiday

Easter

Complete and re-draft report, typeset for final printing.

Term Two

Week 1

Final reading and printing of report.

Week 2

Slack. Emergency use only!



Note that I plan to pick one day per week that throughout design and development will be spent adding to the final report. It is very tempting in a fever of coding to ignore documentation. I must not do this.

Note also that since I hope to use skills acquired during the second term I am forced to delay the design of robots until near the end of development. Bear in mind that my definition of 'success' does not include having working computer players.


Resources

Since this is a software project, my resource use will be minimal. Much development will take place on my Gnu/Linux workstation, starfish. Work will be backed up and tested daily on the DCS Sun workstations. A cron job on stone will provide daily compressed development snapshots, and copying these to CSV machines for 'safe keeping'. These snapshots will be pruned on a weekly basis to conserve disc space.

Due to the existence of xrsh my development can be performed on a colour capable X machine so the death of starfish would be insignificant in the grand scheme of things.

Testing can take place under Windows 95 as well providing at least 4 different types of Java Virtual machine to test on (Sun JDK, Kaffe, Netscape and IE4), this will ensure that Java's cross platform ability is realized..


Copyright © Daniel Thompson