kleine Fragen eines Anfängers

  • Themenstarter Themenstarter Ozy
  • Beginndatum Beginndatum
O

Ozy

Gast
Hallo Gemeinde,
nachdem wir jetzt in diesem Semester eine Java-Vorlesung hatten und mir Java doch mehr gefallen hat als C (zumindest im Bereich der Desktopprorammierung) hab ich mich daheim jetzt bisl hingehockt und rumgespielt.

Ich versuche mich gerade an der Implementierung des "Game of Life" noch Conway.
Der Algorithmus läuft soweit, auf einem kleinen Versuchsfeld (nur 4*4 bis jetzt) klappen die ersten Tests, das Spielfeld ist soar schon Torrusförmig 🙂

Später soll noch eine Möglichkeit kommen, "Universen" aus Textdateien zu laden, aber momentan geschieht das Setzen der Startformation komfortabel in einem GUI, wobei jede Zelle des Spielfelds durch eine Klasse "Zelle" repräsentiert wird, die von JButton erbt. Und zwar deswegen, weil ich per Aktionevent (klick auf den Button) sehr leicht eine Startformation zusammenklicken kann.

Zusätzlich hat jede Zelle noch Attribute, zB ihre Koordinaten, ihren Zustand etc. Ausserdem haben alle Zellen einige static-Attribute gemeinsam, die Hauptsächlich ihr Design betreffen, zB Farben, Größe etc. Ausserdem exisitieren Methoden um Zellen zu töten, wiederzubeleben, und sogar eine zufällige Verteilung mit einer gewissen Population (in %) zu ermöglichen. Aber das ist nebensächlich 🙂

Da mein Algorithmus funktioniert arbeite ich an einer komfortablen GUI.
Danach soll es möglich sein,das Spielfeld beliebig groß zu machen, und auch per Regler die Wachstumsgeschwindigkeit zu ändern.

Wie gesagt, in Java bin ich noch nicht so lange dabei. Deshalb meine Frage:
Ist mein Lösungsansatz, jede Zelle als JButton zu realisieren, überhaupt sinnvoll?
Ich meine, wenn ich mal ein 100*100 Spielfeld anlege, das gibt 10k Buttons.
Das ist doch bestimmt recht Speicherintensiv. Ich weis ja nicht was 10k Buttons (die alle noch ca. 10 Attribute haben) an Speicher verschlingen.
Und rechenintensiv doch bestimmt auch? Der Algorithmus greift zwar auf ein Array aus enum-Werten zurück, aber nach dem berechnen müssen trotzdem alle Zellen (respektive Buttons) die sich ändern getötet oder gerezzt werden.

Wie würdet ihr das machen? Oder denkt ihr ich kann meinen Ansatz weiterverfolgen?

Bin über Hilfedankbar,
MfG Ozy
 
Ich hab das ganze auch mal programmiert und ich denke mit dem Ansatz für jede Zelle einen JButton zu verwenden wirst du nicht sehr weit kommen.
Bei nem größeren Feld wird dir da wohl die performance flöten gehen 🙂

Ich habe damals intern ein boolean[][]-array verwendet und als Darstellung auf der Gui ein BufferedImage verwendet (schwarz/weiße Pixel).
Auf diesem Image kannst du dann einen MouseListener registrieren und die Mausklicks an dein Model weitergeben, das funktionierte eigentlich recht gut.
 
Zuletzt bearbeitet von einem Moderator:
Ist mein Lösungsansatz, jede Zelle als JButton zu realisieren, überhaupt sinnvoll?
Ich meine, wenn ich mal ein 100*100 Spielfeld anlege, das gibt 10k Buttons.
Das ist doch bestimmt recht Speicherintensiv. Ich weis ja nicht was 10k Buttons (die alle noch ca. 10 Attribute haben) an Speicher verschlingen.

Viel. ZU viel. Ich hatte schon mehrfach hierauf verlinkt: was in einer JComponent so alles drin steckt... Abgesehen davon: Setzt du die Farben jetzt mit setBackground oder so? Das dürfte dann insgesamt ziemlich langsam werden...

Man könnte, wie EikeB beschrieben hat, einen boolean[] oder boolean[][] array verwenden, vielleicht auch irgendeinen anderen Typ. (Man könnte (!) auch in Erwägung ziehen, das Spielfeld direkt ein BufferedImage sein zu lassen, aber da sollte man genau überlegen und muss aufpassen, dass Modell und Visualisierung noch semantisch getrennt sind (man also erstmal nicht überall weiß, dass das Spielfeld ein BufferedImage ist)).

Am einfachsten wäre eigentlich ein 2D-Array, aber etwas flexibler und ggf. einfacher zu verwenden wäre ein interface, das im wesentlichen die Funktion eines 2D-Arrays hat, bei dem Implementierungen dann aber z.B. das Torusverhalten oder irgendein anderes Verhalten schön gekapselt zusammenfassen und anbieten kann.
 

Neue Themen


Zurück
Oben