THE LEIPZIG STAR PACKAGE MANAGEMENT
***********************************

1.THE L*PM TEAM...

We are team of six students from leipzig
university named  Mirko, Georg, Manja,
Michael and Patrick. We have had a functional
programming course teached by Prof. Gerber and
Dr. Waldmann who took part in parts of the 
coding.


3.HOW TO READ OUR SOURCE.

The world (/World..) has all informations about 
the robotworld. There you can find the complete
landscape and this module holds all the information
you got and get during the game. Other modules
can send questions to it (/World/Query..) and get
all of the stored informations. The world updates
itself with new informations you get every round.

In /Util you find main-utilities everyone can use.
There are also restrictions and hacks we need to
get more speed and to prevent crashes. A module
debug gives the option to find errors and make
debug output.

/Samples is a short utility to create samplemaps.
Just store your tiles with filename k* (where
* is a number) and creates the mapfile and 
packagefile. Just look the code.

In /Patti lives our robot. With his modules and 
the "flood"-calculation from the module /Geo he 
tries to survive in this violent world.

The main strategy is to create a voronoi graph
and calculate a distancemap.
You can imagine this calculation like a flood
over the map. There flows water from every 
base into the world and if two waves meet 
each other we make a distance-border. 
In a complexer way we get a short way from 
two points. If you want to know more 'bout
that stuff -> rtfc.


3.THE TRICKS OF L*PM IN DETAIL

   
DISTANCE MAP: 
For orientation in the map we use segments of a 
Voronoi-Diagram which is spanned
by the HomeBases. The Diagram is constructed by a
"flooding"-algorithm (compare
recent flooding-catastrophy in East-Germany 
(inspired by that). Between the parts
that are created the Dijkstra-Algorithm is used to 
compute shortest paths.
Every point in the distance map is evaluated by the 
number of steps to the closest HomeBase.   

BIDDING: 
we always bid +1 (except near water and near other robots).
First we test whether we can drop packages. 
Then we test whether there's some
packages to pick up. The packages are sorted in 
packages that can be reached and
packages which can not be reached. These are dropped immediately. 
Next we look for the next destination - namely we try
to reach this position which
need not neccessarily be a package destination.
If that is the case we check for other nearby robots. 
Are there no robots we go one
step towords destionation, otherwise we reconsider our strategy. 
If we don't have a destionation we compute one. 
We compare destionations by factors:
    - HomeBases
    - fields where dropped packages from others 
      robots exists (we log that during game)
    - deliver packages (ordered by: "weight/distance")

There are functions to keep a certain distance to water.   
  
The programming itself. Apart from breaks for sleeping 
on the keyboard we've been
working the whole 72 h. We were especially inspired by 
the task as we had a similar
task during the recent term. 
  
Altogether we generated some 5000 lines of code 
purely in Haskell.
We tested our Robots in self-generated maps. 
The maps have maximum size (1000 x 1000)
to check that the program is not using more sources 
than are submitted by Jury.
  
  
SCHEDULE OF OUR PROGRAM AFTER EXECUTION:


  1. Main.hs:
     -> just calls Run in Main/Run.hs

  2. Run.hs:

     run
     -> connect to server + port
     -> calls World.create in World/Create.hs
     -> calls segment_by_homes in Geo.Segmentation.hs
     -> calls loop in Run.hs

     loop
     -> calls simple and patti2 (as in suggestors) in 
        Main.Simple.hs and Patti.Patti2.hs
	
	
  3. Patti.Patti2.hs:

     patti2
     -> looks, if to drop something (if yes: it is done)
     -> looks, if to pick something (if yes: )
     -> looks, if bag is filled (if yes:, if no:)
