[Munir]

Grüße euch!
Ich lerne seit einiger Zeit Java bei meinem neuen Arbeitgeber, und werde auch ab Oktober Informatik studieren. Ich würde sagen meine Grundkenntnisse in Java sind mittlerweile doch sehr stabil.

Jetzt hatten ein Kumpel und ich die glorreiche Idee zusammen ein kleines 2D Spiel zu entwickeln - nicht erschrecken: Es soll ganz einfach sein! Unser erstes Ziel ist erstmal nur, ein Objekt mittels Tastatureingaben einfach nur von links nach rechts zu bewegen. Aber es scheitert bereits daran.

Schnell sind wir auf LWJGL und Slick gestoßen, aber mir fehlt irgendwie ein gutes Schritt für Schritt Tutorial. Vielleicht kennt jemand eines oder kann mir selbst weiterhelfen? Wäre spitze!

Bis dahin schon mal vielen Dank!

[Kellendil]

Ich habe mal ein kleines Java-2D-TopDown-Action-Spiel mit Swing angefangen, sollte eigentlich nicht so schwierig sein, auch ohne irgendeine Library. Wenn du ein konkretes Problem hast, kann ich vlt. helfen (hab auch noch den source von meinem "Spiel" rumliegen falls Interesse besteht).

[jabu]

^Anhand eines fertigen Spiels ohne fette Libraries die grundlegenden Prinzipien nachzuvollziehen, ist gut! Desweiteren:

Tante Google spuckt einiges aus (gibt sicher mehr):
http://tutorialedge.net/lwjgl-3-keyb...nners-tutorial
http://wiki.lwjgl.org/index.php?titl...s_Example_Game
http://ninjacave.com/tutorials
http://www.java-gaming.org

Viel wichtiger als Libraries, welche mal so und mal so gestrickt sein können, sind bei der Spieleprogrammierung Grundlagen. Deshalb möget Ihr Euch mit Anwendungsentwicklung und Spieleprogrammierung als solches beschäftigen. Ganz wesentlich sind:

- Game Loop
- Message Handling
- Callback Functions
- Blocking versus Non-Blocking Calls/Functions/IO
- Event Handling
- Timing
- evtl. Threads, dann auch deren Synchronisierung


Bereits am Anfang der Entwicklung sollte man sich im Klaren sein, welches Paradigma man primär unterstützen möchte:

a) Normale Anwendung: Kontrollfluss vom System (per I/O ausgelöst) gesteuert, System erhält Kontrollfluss von Anwendung zurück (per blocking function), sobald alle Aufgaben abgearbeitet sind:

• geringe CPU-Auslastung (keine, wenn nichts zu tun ist)
• simples Input Handling möglich
• simples Timing möglich
• simples Event Handling bei simplen Interaktionen über vorhandene Message Queue möglich, aber wegen Gefahr einer unbeabsichtigten Endlosschleife in manchen Situationen nicht immer sinnvoll
• Spielfortschritt von Messages ausgelöst: Spiel bleibt stehen, wenn alles abgearbeitet ist und wartet auf Messages, welche von Benutzereingaben ausgelöst wurden (blocking)
  -> Callback erhält Messages von Betriebssystem/Framework/Library und muss die filtern, verarbeiten und die gewünschten Aktionen bzw. Spielfortschritte auslösen

b) Echtzeitsimulation: Kontrollfluss vom Game gesteuert, welches ständig die Loop durchläuft

• hohe CPU-Auslastung (typisch knapp 100 %, bei simplen 2D-Spielen unterer zweistelliger Bereich möglich, selten einstellig, wird jedoch nicht 0)
• komplexes Input Handling
• nichttriviales Timing
• Event Handling erfordert größeren Minimalaufwand, lohnt sich jedoch mit zunehmender Komplexität bei der Interaktion
• Spiel läuft selbsttätig weiter, wartet nicht auf Messages, auch nicht zu deren Abfrage (non-blocking)
  -> Callback im normalen Spielfluss ohne Funktion

c) Ein Hybrid aus a) und b)

• stimmt überwiegend mit b) überein, arbeitet den Input, sofern im jeweiligen Schleifendurchlauf vorhanden, trotzdem über eine Callback-Funktion nach a) ab, wartet aber nicht innerhalb der Schleife, bis eine Message vorliegt (non-blocking)
• Manche Frameworks, Libraries oder APIs bieten nur ereignisgesteuerte Verarbeitung über einen Callback an, was das Input Handling zwar für simple Programme, welche eher nach a) ablaufen, stark vereinfacht, aber sich bei Nutzung von b) oder c) als umständlich erweist und einen vor die Aufgabe stellt, Zeitstempel zu verarbeiten, verspätete oder überzählige Events zu droppen und eine Synchronisierung mit den Frames zu implementieren. Einfacher wäre, wenn man seine Input-Daten je Frame aus einem Array auslesen könnte.
• Vorteil: Eingabesprachen können, je nach gegebener Funktionalität, durch das Betriebssystem, die Implementierung der Programmiersprache oder das Framework behandelt werden, was die Internationalisierung erheblich vereinfacht.
• Vorteil: Der Aufwand, um zwischen a) und c) umzuschalten, ist gering.

Die Anwendung bzw. das Game kann so ausgelegt werden, dass es mal mehr nach Schema a), b) oder c) abläuft, wenn man den Aufwand nicht scheut. Spieleengines, welche eigenständig ablaufende Welten simulieren, verfolgen Schema b) oder c), während eine Brettspielsimulation, welche auf Benutzereingaben wartet, weitaus simpler, nach a) möglich ist.

Java-Fragen können andere viel besser beantworten (z.B. Kellendil). Grundsätzliches, zum Aufbau eines Games, wie es hier abgehandelt wurde, geht schon in Ordnung. Das ist hier nur ein kurzer Abriss, um einen Rahmen zu liefern, wofür man sich interessieren sollte, um einen groben strukturellen Überblick zu erhalten. Vieles ist bewusst allgemein gehalten, damit man es auf unterscheidliche Systeme, Sprachen, Frameworks, Libraries übertragen kann, ohne dass es seine Gültigkeit verliert.

-> "Messages" können "Nachrichten" oder "Events" heißen.
-> Anstelle eines "Callbacks", welcher vom System aufgerufen wird, kann eine Funktion gemeint sein, welche von einem anderen Thread aus aufgerufen wird, welcher einen "Dispatcher" beinhaltet. Im Grunde ist das Konzept ähnlich, mit dem Hauptunterschied, dass der Dispatcher anstatt im Betriebssystem in der Anwendung, im Framework oder in einer Library (z.B. in der Sprachimplementierung bzw. Laufzeitumgebung) steckt. Natürlich muss der seinerseits wieder in einer Betriebssystemfunktion blockieren oder als Callback aufgerufen werden, weshalb das im Wesentlichen eine Kapselung ist, ohne dass sich am Prinzip etwas ändern würde.

[Munir]

Hey, danke euch jabu und Kellendil! So schnell hab ich nicht so viel Input erwartet

@Jabu
Also ich werde mich mal mit meinem Mitstreiter zusammensetzen und ein wenig beraten. Unsere Hoffnung ist, ganz ganz klein mit einer Mini-Anwendung anzufangen und die dann immer weiter auszubauen je mehr das Wissen und das Können kommt. Vom ersten spontanen Lesen muss ich sagen dass ich in Richtung b) oder c) deiner Möglichkeiten tendiere. Aber wie gesagt, kommt Zeit kommt Rat und damit auch die Ideen wie ich hoffe

@Kellendil
Ich werde dir gleich mal eine PM schreiben, es scheint du bist mein Mann für sowas jetzt

(hab auch noch den source von meinem "Spiel" rumliegen falls Interesse besteht)

Und da hab ich auf jeden Fall Interesse dran, was dabei lernen kann ich auf jeden Fall

Also, bin aber nach wie vor auf weiteren Input gespannt und halte euch auch auf dem Laufenden wenn sich was ergibt oder ich etwas gutes finde

[Sergej Petrow]

Ich hab vor zwei Jahren ein kleines 2D-Programm mit Java geschrieben.

http://forum.worldofplayers.de/forum...41762-Snakezzz

Falls da Interesse besteht, kann ich die Qelltexte zukommen lassen. Da ist etliches an Problemen, die ihr wahrscheinlich jetzt auch habt,
ebenso aufgetaucht. Die wurden aber alle so und nach gelöst, incl. eines Startes mit einer Exe-Datei mittels C.

[Kellendil]

Hier nochmal mein Source: http://upload.worldofplayers.de/file...mev0.4_src.zip

Allerdings sollte man dringend das repainting ändern, das wird hier nämlich auf nem JFrame ausgeführt, sollte aber ein Canvas sein (wahrscheinlich flimmert es auch deswegen).

[Feuerstern]

Ich entwickle im Moment auch ein 2D jump and run in Java für Android.
Bei allgemeinen Game Development fragen wie z.B. bestimmte Techniken zur Kollisionsabfrage hat mir auch die
Seite oft geholfen:
http://tutsplus.com/
Da gibt es einige gute Tutorials. Meistens zwar nicht auf eine bestimmte Sprache bezogen, aber das ist bei solchen Fragen nicht wierklich relevant.
Wünsche euch viel Spaß mit eurem Projekt