1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Anwesend waren:

Cuntz, Nicolas
Gehweiler, Joachim
Hirsch, Martin
Hußmann, Michael
Rödig, Volker
Ruwwe, Christian
Sinnerbrink, Holger
Wichmann, Heiko
Zarbock, Markus

Fragen zur Arena:

• Form der Arena: auf jeden Fall konvex, am besten als mxn-Matrix (muß aber noch von der Schnittstellengruppe entschieden werden)
• Ausrichtung der Sechsecke: oben und unten flache Seite, rechts und links Spitzen (muß aber auch noch von der Schnittstellengruppe bestätigt werden)
• Hinweis: Die Sechsecke müssen regelmäßig sein!

Ergebnisse der Untersuchung des Produkts der Gruppe 9 aus dem letzten Jahr:

• Positives:
  • Dynamischer Lademechanismus der Roboterklassen
• Negatives:
  • Spielanleitung kaum vorhanden
  • Schlechte Übersicht, welche Roboter(-listen) mittels des FileChoosers geladen werden können
  • Man kann nicht sofort loslegen; Änderungsvorschlag: Default-Roboterliste automatisch laden
  • Keine Fehlertoleranz (z.B. Hinweis, daß man erst Roboter laden muß, statt einfach Buttons deaktivieren)
  • Diverse Bugs:
    • Zeitanzeige nicht immer korrekt
    • keine Scrollmöglichkeit in der Spielanleitung und Arena-Designer
    • Versionsdialog paßt nicht in Frame
    • Zoom funktioniert teilweise nicht
    • Repaint-Fehler
  • Arena-Styles fressen zuviel Resourcen (teilweise blockiert deshalb das ganze Programm)
  • Zuviel Gewicht auf Spielereien (Arena-Styles, Zwischensequenzen, "destruction" und "earthquake", etc.) gelegt
  • Statusanzeige der Roboter besser in gesonderter Tabelle (statt integrierter Baumansicht)
  • Programm hängt sich auf, wenn Roboter blockieren, da der Thread die Kontrolle an den Roboter abgibt (da die Beseitung dieses Problem jedoch recht kompliziert ist, muß das ggf. noch mal gesondert diskutiert werden)

Sinn des Stellvertreter-Objekts:

• Dient zur (sicheren) Kommunikation der Arena mit dem Roboter
• Daten des Roboters werden im Stellvertreter-Objekt gehalten
• Arena hat Schreibrechte, Roboter nur Leserechte; dazu ist die Klasse im Package der Arena anzusiedeln; die get-Methoden sind public, die set-Methoden haben nur Package-Visibility

Hinweise:

• Together macht gerne den Fehler, statt einer (pfeilspitzenlosen) Linie zwei (entgegengesetzte) Pfeile zu erstellen
• Von einer der anderen Gruppen kam der Vorschlag, zwei Beamer zu nutzen (einer für die Darstellung der Arena, einer für den Rest), wobei die Programmteile über RMI oder TCP/IP kommunizieren müßten; der Vorschlag wurde nicht begrüßt, kann aber nur in Übereinstimmung mit den anderen Gruppen abgelehnt werden; sollte das nicht gelingen, wird Kommunikation via RMI der anderen (TCP/IP) vorgezogen

Verteilung weiterer Aufgaben:

• Implementierung: Michael Hußmann
• Redesign: Heiko Wichmann
• Reengeneering: Holger Sinnerbrink
• Test(-szenarien): Christian Ruwwe