PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : 2D Spiel in Java programmieren


Sliver21
2007-04-02, 16:40:27
Hallo Jungs,
ich habe folgendes Problem. Wir müssen als über das Sommersemester (2. ) ein Spiel in Java programmieren. Im ersten Semester haben wir die Syntax und die Konzepte von Java ( Kapselung, Vererbung, Polymorphismus...) gelernt. Nun heißt es, die gelernte Theorie in die Praxis umzusetzen. Natürlich muss es objektorientiert programmiert sein. Von der Ansicht her soll das Spiel ähnlich wie Micro-Maschines werden. Es gibt viele Fahrzeuge, die durch die Stadt fahren ohne zusammenzustoßen. Man steuert selbst auch ein Fahrzeug auf der Karte. Es gibt auch einen Gegner, der durch die Stadt fährt...

Noch sind wir ganz am Anfang und überlegen uns, welche Klassen wir anlegen müssen. Jetzt kommen die ersten Probleme, wir wissen nicht, wie wir das Konzept aufbauen sollen. Beispiel: Es wird eine Klasse Fahrzeug geben, von der viele Objekte instanziert werden; wo sollen dann die Collections hin, die diese Objekte verwalten? Wie erfolgt die Steuerung? Wie wird die Kollisionsabfrage objektorientiert gemacht? Wie sieht ein Spielstart überhaupt aus? Zu Beginn muss man ein paar Einstellungsmöglichkeiten haben, zB. die maximale Anzahl an Autos uvm, danach startet das Spiel. Man muss es natürlich auch so designen, dass die GUI von der Funktionalität getrennt ist. Zum Schluss muss es auch noch netzwerkfähig sein. Umso wichtiger ist es also, dass das Konzept von Anfang an gut durchdacht ist.

Kennt jemand von euch vielleicht ein Buch, in dem es um einfache Spieleprogrammierung in Java geht? Das Hauptaugenmerk liegt dabei erstmal auf dem objektorientierten Aufbau.
Ich bin für jeden Tipp sehr dankbar!

darph
2007-04-02, 17:34:25
http://en.wikipedia.org/wiki/Model-view-controller (Logik von Eingabe von Präsentation trennen)
http://en.wikipedia.org/wiki/State_pattern (einen Status durch Objekte repräsentieren. Ich bin im Hauptmenü / Ich bin im Spiel etc...)

darph
2007-04-02, 17:36:44
Umso wichtiger ist es also, dass das Konzept von Anfang an gut durchdacht ist.
Bei uns war es so, daß man vor dem Software-Engineering-Praktikum die Vorlesung Software Engineering gehört haben mußte. Sowas gibt's bei Euch doch gewiß auch. Dort werden verschiedene Methoden zum Softwareentwurf vorgestellt. Hier bietet sich euch das Wasserfallmodell (http://de.wikipedia.org/wiki/Wasserfallmodell) an.

Monger
2007-04-02, 18:10:38
Falls nicht bereits geschehen, solltet ihr auf jeden Fall eine Blick auf die Sun Tutorials (http://java.sun.com/docs/books/tutorial/index.html) werfen. Da sind alle technischen Themen zumindest mal angeschnitten. Das wird nicht reichen um sich da vollends in Getümmel zu werfen, und manchmal ist man mit einem ganz anderen Ansatz (alternative Frameworks nicht vergessen!!) einfach besser dran. Aber es hilft zur Orientierung.

Ich kann dir zum Projektmanagement leider nicht viel sagen. Ich hatte ein Buch was mich schwer beeindruckt hat namens "Der Termin" von Tom deMarco. Aber wenn man unter Zeitdruck steht, hat man wahrscheinlich nicht den Nerv dazu, sich jetzt noch irgendwelche Prosa reinzuziehen.

Halt dich halt an das was du (hoffentlich! ;) ) gelernt hast: halt die Struktur so offen und flexibel wie möglich, reduzier die Abhängigkeiten zwischen verschiedenen Programmteilen so weit es Sinn macht, und hol dir regelmäßig und frühzeitig Leute ran die unvoreingenommen über deine Arbeit urteilen können.

Sliver21
2007-04-02, 21:46:26
Danke für eure Beiträge! Software Engineering habe ich nicht und werde ich auch nicht haben.

Monger, dein Tipp mit der Struktur ist einfacher gesagt als getan, jedenfalls für mich. Wir hatten bisher noch nie etwas größeres programmiert. Ich hatte erhofft, dass jemand von euch ein gutes Java Buch kennt, in dem es um Spieleprogrammierung geht. Ich hab letztens ein Spieleprogrammierbuch ausgeliehen, dieses ist aber leider nur für Flash.

An sich gibt es sehr viele Spieleprogrammierbücher, schon allein von Lamothe. Aber diese sind leider fast (?) alle in C oder C++ und das ist nicht so wirklich das, was wir brauchen. Gedanken an Performance und Optiemierung interessieren uns auch recht wenig, Hauptsache ist ein kluger Design.

Weiß jemand von euch, wie ich die Kollisionabfrage machen kann? Die Autos fahren in dem Feld herum, ohne mit anderen Autos oder Wänden zu kollidieren. Folgendes habe ich mir schon überlegt: Ich brauche eine Klasse Fahrzeug, in der die Koordinaten des Fahrzeugs bezogen auf die Karte gespeichert werden, wie auch die aktuelle Geschwindigkeit und einen Winkel, der die Fahrtrichtung bestimmt. Die Anzeige soll so arbeiten, dass das eigene Auto stets in der Mitte ist und die Welt immer bewegt wird, sobald das Fahrzeug fährt. Ich habe mir da gedacht, dass es einen 'Zeichner' geben muss, dem als Parameter eine Referenz auf eigene Fahrzeug übergeben wird, welches in der Mitte dargestellt wird. So könnte man diesen Zeichner dann auch für die Clientapplikation verwenden, wobei jeder Spieler einen eigenen Zeichner hat. Ach ja, was ich fragen wollte, wo sollte eine Kollisionsabfrage erfolgen? Ist dies nicht, rein formal gesehen, schon Teil der Spiele Engine?

RMC
2007-04-02, 22:08:14
Ach ja, was ich fragen wollte, wo sollte eine Kollisionsabfrage erfolgen? Ist dies nicht, rein formal gesehen, schon Teil der Spiele Engine?

Kollissionsabfrage (reine Implementierung) ist normalerweise Teil einer guten Spieleengine, ja. ´

Wird im Normalfall mit Axis-Aligned/Oriented Boundingbox und Boundingsphere-Algorithmen durchgeführt.

minos5000
2007-04-02, 22:13:35
Wir mußten am Anfang vom Studium auch ein Spiel programmieren ohne je gelernt zu haben wie man dabei vorgeht.
IMO gehört das zum Lernprozeß dazu dazu, sich von Anfang an selber Gedanken über alles zu mache. Hier habt ja sicher einen Tutor, der euch über die Schulter schaut und hilft falls ihr euch verrennt.

Eine Vorlesung über Software-Engineering Methoden hatte ich erst 5 Semester später, hätte mir in dem Fall auch nicht wirklich was geholfen.

Spasstiger
2007-04-03, 01:40:34
Bin bei einer schnellen Googlesuche nach "Spieleengine" und "Klassendiagramm" auf das hier gestoßen:
Steuerung von autonomen Vehikeln in einer Echtzeit-3D-Umgebung (http://www.f4.fhtw-berlin.de/people/tj/da/ziep.pdf)

Vielleicht hilft dir das weiter, ist zwar für ein 3D-Spiel, aber die grundsätzlichen Klassenstrukturen für Wegfindung, Kollisionsabfrage, etc. kann man ja auch für eine 2D-Engine übernehmen.

RoKo
2007-04-03, 21:13:25
Wenn man seine ersten Spiele programmiert, sollte man das Design nicht zu "klug"/kompliziert anlegen, sonst verrennt man sich. Die Algorithmen sind ohnehin wichtiger.
Das Fundament eines Spiels ist die MainLoop, eine Endlosschleife die nacheinander Benutzereingaben abfragt (ala if 'b' gedrückt, chefauto.schneller()), Physik und dann Grafik berechnet, so oft/schnell wie möglich.
Physik/Kollision/Bewegung: Für jedes Auto einen Kreis denken. Für jedes Auto: bewegen (aktuelle Richtung * Geschwindigkeit * delta t), auf Kollision gegen alle anderen Autos bzw. Kreise testen, bei Kollision das aktuelle Auto wieder zurückbewegen. Ineffizient und ungenau, aber funktioniert. Über effiziente Kollisionsroutinen kann man Diplomarbeiten schreiben.
Für die Einstellungen zu Beginn des Spiels dürfte eine normale Java-GUI reichen. Beim Start wird dann das Spielfenster geöffnet und die MainLoop aufgerufen.
Netzwerkfähig... viel Spaß ;) Immer den Kontakt zum Tutor halten, bei Spielen kann man sich leicht übernehmen.

Und ruhig ein C/C++-Buch zur Spieleprogrammierung nehmen. Die Sprache ist zweitranging. Oder mal ein wenig in Artikeln auf http://www.gamedev.net und ähnlichen Seiten wühlen.

buchrabe
2007-04-03, 22:04:25
http://www.amazon.com/Black-Art-Java-Game-Programming/dp/1571690433
Das Buch ist ziemlich gut, es eklärt in den ersten Kapiteln ein paar Javagrundlangen anhand von Beispielen z.B. Spriteklasse, davon abgeleitet Quadrat,Kreis usw.
Dann wird pro Kapitel ein kleines Spiel geschrieben, z.B. Spaceinvader, wobei man immer etwas dazu lernt wie z.B. sockets für den Highscore-Server, simple Kugel gegen Kugel Kollision für ein Spiel wie das erste Starfox usw.

Ich hoffe du kannst das noch irgendwo ergattern.

Kinman
2007-04-04, 00:05:03
Wenn man seine ersten Spiele programmiert, sollte man das Design nicht zu "klug"/kompliziert anlegen, sonst verrennt man sich. Die Algorithmen sind ohnehin wichtiger.
Das Fundament eines Spiels ist die MainLoop, eine Endlosschleife die nacheinander Benutzereingaben abfragt (ala if 'b' gedrückt, chefauto.schneller()), Physik und dann Grafik berechnet, so oft/schnell wie möglich.
Physik/Kollision/Bewegung: Für jedes Auto einen Kreis denken. Für jedes Auto: bewegen (aktuelle Richtung * Geschwindigkeit * delta t), auf Kollision gegen alle anderen Autos bzw. Kreise testen, bei Kollision das aktuelle Auto wieder zurückbewegen. Ineffizient und ungenau, aber funktioniert. Über effiziente Kollisionsroutinen kann man Diplomarbeiten schreiben.
Für die Einstellungen zu Beginn des Spiels dürfte eine normale Java-GUI reichen. Beim Start wird dann das Spielfenster geöffnet und die MainLoop aufgerufen.
Netzwerkfähig... viel Spaß ;) Immer den Kontakt zum Tutor halten, bei Spielen kann man sich leicht übernehmen.

Und ruhig ein C/C++-Buch zur Spieleprogrammierung nehmen. Die Sprache ist zweitranging. Oder mal ein wenig in Artikeln auf http://www.gamedev.net und ähnlichen Seiten wühlen.

imho ist so ein Spiel optimal für Multithreading.
Wir haben so etwas ähnliches (weitaus wenigr umfangreich) bei der Behandlung von Threads und Observer Pattern programmiert. Ging relativ leicht das ganze

mfg Kinman

Monger
2007-04-04, 08:43:29
imho ist so ein Spiel optimal für Multithreading.

Imho nicht. Damit fängt man sich nur Probleme ein, ohne irgendeinen erkennbaren Nutzen zu haben. Die Gameloop garantiert, dass alles in der richtigen Reihenfolge und im richtigen Takt abläuft. Sobald man nebenläufig irgendwelche Threads laufen lässt, muss man sich erst wieder Gedanken machen wo genau man denn die synchronisiert.
Imho sollte man Threads wirklich erst dann nutzen, wenn man förmlich über einen entsprechenden Anwendungsfall fällt, aber nicht früher.

EgonOlsen
2007-04-04, 10:56:21
imho ist so ein Spiel optimal für Multithreading.
IMHO auch nicht. Für Netzwerk u.ä.: klar! Für die Spiellogik: Auf keinen Fall. Man handelt sich mehr Probleme ein, als es löst. Ein schönes Extrembeispiel: http://worsethanfailure.com/Articles/Sprite_Threading.aspx

Hucke
2007-04-04, 12:26:06
Bei O'Reiley hab ich ein Buch zu Java Game Programming gefunden. Weiß leider nicht mehr den Titel. Das hat jedenfalls ne schöne Einführung zu diesem Thema gegeben. Als Beispiele waren einfache Platform Spiele (ähnlich Super Mario) angeführt. Wir haben dann in einer kleinen 24h Bastelei einen Sidescroller darauf basierend geschrieben. Wenn Du magst kann ich Dir den Source dazu mal zukommen lassen.
Allerdings ist das Zeug nicht sonderlich ausgereift. Einfacher Hintergrundsound per midi, Animationen per Threads und das wars auch schon an Schnickschnack. :D

Der_Donnervogel
2007-04-04, 12:39:27
imho ist so ein Spiel optimal für Multithreading.Prinzipiell wäre Multithreading schon denkbar, aber der Threadstarter ist im 2. Semester und macht vermutlich seine erstes etwas größeres Progamm. Seine Aufgabenstellung ist dafür bereits nicht ohne, da jetzt auch noch Multithreading reinpacken zu wollen wäre völlig übertrieben. Mit Multithreading kann man sich schneller Probleme einhandeln als einem lieb ist. Dazu kommt dann noch, daß die dann auch noch schwieriger zu finden und beheben sind als bei einer simplen Gameloop.Wir haben so etwas ähnliches (weitaus wenigr umfangreich) bei der Behandlung von Threads und Observer Pattern programmiert. Ging relativ leicht das ganzeIch gehe mal davon aus, daß der Threadstarter noch keine Patterns kennt. Deshalb würde ich ein Vorgehen nach dem KISS-Prinzip vorschlagen. Keinen Schnickschnack (z.B Patterns) einsetzen den man womöglich eh (noch) nicht richtig versteht sondern lieber die einfachen, selber gemachten Lösungen bevorzugen, selbst wenn sie schlechter sind. Sonst ist die Gefahr sich zu verzetteln riesengroß.

Sliver21
2007-04-04, 22:20:55
Vielen Dank für eure Beiträge!

Zum Thema Threads: In der letzten Zeile zur 3. und letzten Teilaufgabe steht folgendes: "Threads, Threads, Threads, ..." Scheinbar möchte unser Professor sehr wohl, dass wir Threads verwenden. 2 Threads brauche ich doch schon mal, und zwar einen für die Eingabe und den anderen für die Darstellung.

In den letzten Tagen habe ich mir auch schon einige Java Bücher zum Thema Spieleprogrammierung runtergeladen. Ich werde mal schauen, ob ich da etwas sinnvolles finde. Auf den ersten Blick sehen diese ganz gut aus.

EgonOlsen
2007-04-05, 08:27:17
"Threads, Threads, Threads, ..." Scheinbar möchte unser Professor sehr wohl, dass wir Threads verwenden. 2 Threads brauche ich doch schon mal, und zwar einen für die Eingabe und den anderen für die Darstellung.Vielleicht haut er aber auch nur im Takt dazu mit dem Kopf gegen die Wand...:D Du hast üblicherweise den AWT event thread, der zumindest die Mouse- und Keylistener bedient und, wenn du auf Active Rendering verzichtest und den Swing-repaint-Mechanismus nutzt, das Zeichnen der GUI bzw. der Spielgrafik übernimmt. Und du hast natürlich implizit den Thread, in dem dein Spiel läuft. Wenn du Netzwerkunterstützung einbaust, hats du noch weitere dafür. Aber bitte keine Threads für die Spiellogik oder -darstellung nutzen, wenn es nicht unbedingt sein muss. Es sieht auf den ersten Blick sexy aus, keine Frage. Aber es ist keine gute Idee, wenn man ein flüssig und deterministisch ablaufendes Spiel haben will. Vom geistigen und programmatischen Overhead durch Synchronisierung mal ganz abgesehen.

Sliver21
2007-04-05, 17:42:23
Das klingt sehr vernünftig, EgonOlsen.