• First draft of functional specification on Terrain Generation, Optimum route finding algorithm, Graphical Display and Optional Extras

• Mission statement for the Graphical User Interface, structure for Terrain Object

• File Formats in the Terrain, the Route

• Abstract Classes for CanalRoute, MainFrame, Route, RouteVertex, TerrainMap, Terrain, AbstractCostInfo, AbstractGUI

• Terrain Generation Algorithm , Algorithm Specification, Dijkstra’s (unmodified) Algorithm, Improved Algorithm

• CVS up and running, updating thor / webpage hourly (problems with using CVS from dialing in through Magpie has just been solved by putting the IP address in .rhosts each time )

• All Methods need to be defined in the Specification (Objects can be decided later)

• All vertices will be stored in the Route (only vertices)

• CostInfo will be a separate Object, and Coster will be a separate Method

• Algorithm will be under CanalRoute

• The canal route will only restricted to square tiles Dijkstra’s (unmodified) Algorithm uses

• The vertices at the boundaries will be taken as one in the previous square tile of the Route

• Investigation for optimisation will be included in the possible optional extras list rather than the basic requirements

• A submission version of the specification document will be kept in Phebe’s local machine, and the working documents will be in the website.

• Generation of random terrain according to restrictions given by user is not allowed

• The route can be re-analyse for new start and endpoints, and the previous route can be overwritten.

• TerrainMap - load in human readable data file

• Save and load previous files from the Router

• The Interface will have a Zoom and Scroll feature on the display

• Symbols with Legends, for eg. Embankment, cutting, tunnels etc, will generally follow that of the Ordnance Survey Maps, or slightly modified if necessary (Karen will find out the details)

• Load and save of Route will be in binary, export Outputstream will contain human readable data.

• The Specification will include 3 stages :-

• Only a general description for the mouse for the Interface is required.

• Tunnelling under and over impassable square tiles will be not allowed

• Acceptance Criteria – QA, validation & verification, testing, platforms

[Information subsequent to the meeting :

Tools used for the project :-

Group website/internal docs: HTML 4.0

Java 1.2- aiming for cross platform compatibility

CVS 1.10.7 ]

4.0 Next Meeting : Monday 31/1/2000 at 12:00 noon at Cockcroft 4