 |
|
|
Themen-Optionen |
17.04.2008, 15:55
|
Nach oben #3 |
|
Neuer Benutzer
Registriert seit: 17.04.2008
Beiträge: 4
|
programmierrichtlinien
5 Programmierrichtlinien
Das zu erstellende Programm muss entsprechend der Beschreibung in Kapitel 4 entwickelt werden. Insbesondere bedeutet dieses, dass es objektorientiert und nicht etwa prozedural zu programmieren ist. Dabei sind außerdem g¨ angige Code-Konventionen einzuhalten. Die offiziellen ” Java Code Conventions“ k¨ onnen der Seite http://java.sun.com/docs/codeconv/ entnommen werden. F¨ ur den Rahmen dieses Praktikums sind vor allem folgende Konventionen bindend: • Alle Pakete, Klassen, Interfaces, Methoden und Variablen, sollten aussagekr¨ aftige Namen haben. Abk¨ urzungen sind erlaubt, sollten aber nachvollziehbar sein (z.B. ” elem“ f¨ ur Element oder ” nachf“ f¨ ur Nachfolger). Es sind entweder deutsche oder englische Bezeichner erlaubt, aber es sollten niemals mehrere Sprachen gemischt werden 3 . Dar¨ uber hinaus gelten folgende Namenskonventionen: – Paketnamen beginnen mit einem kleinen Buchstaben. – Die Namen von Klassen und Interfaces beginnen mit einem großen Buchstaben. Der Name einer .java-Datei muss (bis auf das Suffix .java) exakt mit dem der entsprechenden Klasse bzw. des entsprechenden Interfaces ¨ ubereinstimmen. Beispiel: class ImageViewer – Methodennamen m¨ ussen mit einem kleinen Buchstaben beginnen. Bei zusammengesetzten W¨ ortern ist der Buchstabe jedes neuen Wortes groß zu schreiben. Methodennamen sollten immer ein Verb enthalten. Beispiele: getName() und calculateNewSituation() – Namen von Variablen m¨ ussen mit einem kleinen Buchstaben beginnen. Bei zusammengesetzten W¨ ortern ist der Buchstabe jedes neuen Wortes groß zu schreiben. Beispiele: String name; und int firstIndex; – Die Namen von Konstanten bestehen ausschließlich aus Großbuchstaben und Underscore-Zeichen. Enth¨ alt ein Bezeichner mehrere Begri e, so werden diese mit einem Underscore verbunden. Beispiel: public static final int MIN_VALUE = 66; • Layout: – Es sollte niemals mehr als eine Anweisung in einer Zeile stehen. 3 Als Ausnahme sind hierbei die ¨ ublichen Getter und Setter zu nennen, d.h. bei der Verwendung deutscher Bezeichner darf getBezeichner() durchaus verwendet werden. 21 8.2 Anforderungen an das Spiel • Es muss ein rechteckiges Spielbrett mit farbigen Atomen und Indikator-Icons dargestellt werden. Die Grafik sollte angemessen ansprechend sein. Eine Implementierung der Spielfl¨ ache aus einem Raster von Schaltfl¨ achen (Buttons) wird beispielsweise nicht akzeptiert. • Die Felder des Spielbretts sollen sich in ihrer Gr¨ oße dynamisch der Fenstergr¨ oße anpassen: Wird das Fenster verkleinert bzw. vergr¨ oßert, so m¨ ussen auch entsprechend die einzelnen Felder kleiner bzw. gr¨ oßer werden. Insbesondere sollen keine Scroll-Leisten verwendet werden, wenn das Fenster verkleinert wird. Außerdem sollte kein Fenster-Bereich unn¨ otig frei bleiben! • Neben dem Spielbrett m¨ ussen folgende Informationen angezeigt werden: – aktuelles Level – aktuelle Punktzahl – ben¨ otigte Punktzahl, um ins n¨ achste Level zu gelangen Ob zur Darstellung dieser Informationen Java-Swing-Komponenten oder selbst gezeichnete Elemente verwendet werden, bleibt Ihnen¨ uberlassen. • Die Atome auf dem Spielbrett m¨ ussen durch einen Linksklick ausgew¨ ahlt werden k¨ onnen. Ebenfalls soll die M¨ oglichkeit bestehen, ein Atom wieder abzuw¨ ahlen bzw. stattdessen ein anderes Atom zu w¨ ahlen. Es muss erkenntlich sein, welches Atom gerade gew¨ ahlt ist. • Durch einen weiteren Linksklick auf ein freies Feld muss das ausgew¨ ahlte Atom bewegt werden k¨ onnen. • Wenn ein Atom ausgew¨ ahlt ist, muss vor der Bewegung klar ersichtlich sein, ob der Weg zum Zielfeld blockiert oder frei ist. Dies soll durch einen Streckenzug vom Start- zum Zielpunkt erfolgen (wie z.B. in Abbildung 2 auf Seite 9  Wenn dasAtom auf das Feld bewegt werden kann, ¨ uber dem sich der Mauszeiger befindet, dann zeigt der Streckenzug den k¨ urzesten freien Weg zwischen den beiden Feldern an (existieren mehrere k¨ urzeste Wege, ist ein beliebiger von diesen darzustellen). Andernfalls wird kein Streckenzug angezeigt. Bei der Bewegung des Mauszeiger muss die Anzeige jedes Mal aktualisiert werden, wenn ein Feld betreten bzw. verlassen wird und ein Atom ausgew¨ ahlt ist. • Die Berechnung eines k¨ urzesten Weges muss (auch bei ung¨ unstigen Spielsituationen) in Echtzeit erfolgen, d.h. ein Algorithmus, der beispielsweise l¨ anger als eine Sekunde ben¨ otigt, wird nicht akzeptiert. Folglich darf der Algorithmus keine in Bezug auf die Anzahl der Felder exponentielle Laufzeit haben. • Wird ein Atom auf ein Indikator-Icon bewegt, so verschwindet das Indikator-Icon sofort. Dabei ist es unerheblich, ob durch die Bewegung des Atoms ein Molek¨ ul entstanden ist oder nicht. 27• Es muss erkannt werden, wann mehrere gleichfarbige Atome ein Molek¨ ul bilden. Ist dies der Fall, dann werden die beteiligten Atome vom Spielbrett entfernt und der Spieler erh¨ alt eine gewisse Punktzahl, die von der Gr¨ oße des Molek¨ uls und den im Konfigurationsdialog eingestellten Werten abh¨ angt. • Sobald die Punktzahl erreicht oder ¨ uberschritten ist, die zum Aufstieg in ein h¨ oheres Level f¨ uhrt, muss eine entsprechende Meldung erscheinen und das n¨ achste Level starten. Die erreichten Punkte bleiben erhalten, d.h. man beginnt das neue Level mit dieser Punktzahl. Auch alle Atome und Indikator-Icons bleiben erhalten. • Am Anfang jeder Runde m¨ ussen die Indikator-Icons durch entsprechende Atome ersetzt werden. Entstehen dabei Molek¨ ule, sind diese zu entfernen und die Punktzahl des Spielers entsprechend zu erh¨ ohen. Außerdem m¨ ussen per Zufallsgenerator die Positionen und Farben f¨ ur die neuen Indikator-Icons berechnet und diese auf dem Spielbrett platziert werden. • Das Ende eines Spiels muss erkannt werden. Das Spielende ist dann erreicht, wenn das Spielbrett bis auf ein Feld mit Atomen gef¨ ullt ist und kein Atom mehr bewegt bzw. nur noch ein einziges Atom zwischen zwei angrenzenden Feldern hin und her bewegt werden kann. • Ein Spiel muss jederzeit beendet werden k¨ onnen. • Ein Spiel muss jederzeit (mit unver¨ anderten Einstellungen) neu gestartet werden k¨ onnen. • Das Programm muss ¨ uber einen globalen Konfigurationsdialog verf¨ ugen, in dem die folgenden Einstellungen vorgenommen werden k¨ onnen: – Einstellen der Basispunktzahl zur Berechnung der Punkte, die der Spieler f¨ ur das Bilden von Molek¨ ulen erh¨ alt. – Einstellen der Punktzahl f¨ ur jedes Level, die n¨ otig ist, um das Level zu gewinnen. – Einstellen der Spielbrett-Gr¨ oße durch Angabe der Anzahl der horizontalen und vertikalen Felder. Der Konfigurationsdialog darf aus einem laufenden Spiel heraus nicht aufgerufen werden k¨ onnen. 8.3 Anforderungen an den Atomica-Editor Zus¨ atzlich zum eigentlichen Spiel sollen Sie noch einen Atomica-Editor programmieren, mit dem man auf einfache und komfortable Weise eigene initiale Spielsituationen erstellen kann. Folgende Anforderungen sind umzusetzen: 28 • Jede initiale Spielsituation bezieht sich auf ein spezielles Spielbrett. Die Gr¨ oße des Spielbretts muss eingestellt werden k¨ onnen. • Die Anzahl der verf¨ ugbaren Farben muss eingestellt werden k¨ onnen. Diese kann beliebig zwischen 3 Farben (entspricht dem Schwierigkeitsgrad von Level 1) und 12 Farben (entspricht dem Schwierigkeitsgrad von Level 10) gew¨ ahlt werden. Beim erweiterten Spielmodus beeinflusst dieser Wert (wie beim normalen Spielmodus) die Punktvergabe. • Atome und Indikator-Icons m¨ ussen in den verf¨ ugbaren Farben auf beliebige Felder des Spielbretts gesetzt werden k¨ onnen. Es k¨ onnen beliebig viele Atome und maximal 3 Indikator-Icons gesetzt werden. Ein Atom kann allerdings nur dann positioniert werden, wenn dadurch kein Molek¨ ul entsteht. Außerdem darf es nicht m¨ oglich sein, ein Atom oder ein Indikator-Icon auf ein bereits besetztes Feld zu setzen. Falls weniger als 3 Indikator-Icons gesetzt worden sind, werden weitere bei Spielbeginn zuf¨ allig auf freie Felder gesetzt, so dass dann insgesamt genau 3 Indikator-Icons vorhanden sind. • Atome und Indikator-Icons m¨ ussen wieder entfernt werden k¨ onnen. • Erzeugte initiale Spielsituationen m¨ ussen persistent gespeichert und sp¨ ater im Editor wieder geladen werden k¨ onnen. • Abgespeicherte initiale Spielsituationen m¨ ussen nachher im erweiterten Spielmodus geladen werden k¨ onnen und somit ” spielbar“ sein. • Die grafische Oberfl¨ ache des Atomica-Editors sollte angemessen ansprechend sein. Eine Implementierung der Spielfl¨ ache zum Beispiel aus einem Raster von Schaltfl¨ achen (Buttons) wird nicht akzeptiert. • Der Editor soll kein eigenst¨ andiges Programm sein sondern muss in das Spiel integriert werden. Aus dem Spiel soll er dann beispielsweise¨ uber ein Hauptmen¨ u, eine Toolbar etc. gestartet werden k¨ onnen. D.h. es darf keine separate .jar Datei oder eine zweite Hauptklasse existieren, sondern Spiel und Editor m¨ ussen zwei getrennte Teile eines einzigen Programms sein. |
|
   
|
|
17.04.2008, 16:42
|
Nach oben #4 |
|
Erfahrener Benutzer
Registriert seit: 15.09.2005
Ort: Königreich Flieden
Beiträge: 491
|
was genau erwartest du jetzt? das sich jemand hinsetzt und dir ne lösung präsentiert?
Dann bist du hier im falschen Forum... Überleg dir doch mal, wie du an das Projekt rangehen möchtest. Welche Regeln gelten für das Spiel und was muss alles im Programm umgesetzt werden? Dann muss du dir Gedanken machen, wie das konkret als Java-Programm gelöst werden kann. Auch wenn du ein Anfänger bist, solltest du da irgendeine Idee haben. Bei allem können wir dir hier im Forum helfen, deine Ansätze beurteilen und Tipps geben, aber die Initiative muss von dir ausgehen. Hier wird sich niemand finden, der dir die Arbeit abnimmt, wir können dich lediglich so gut es geht unterstützen und mit Rat und Tat zur Seite stehen. Ich empfehle dir erstmal das Turorial von WarrenFaith zur Entwicklung eines Projektkonzeptes durchzulesen, auch wenn manches vielleicht für dich garnicht zutrifft, oder z.B. schon Coding Guidelines bestehen, ist diese Lektüre durchaus hilfreich.
__________________
Weißt Bescheid - Scheiß wie weit |
|
|
|
