Hilfe beim Design (Stichwort OO, Pattern, ...)

[hdi]

Hey Jungs,

kleine Warnung: Es folgt recht viel Text, und um antworten zu können muss man sich wahrscheinlich ziemlich viele Gedanken machen, also wer auf sowas grad keine Lust hat, sollte jetzt besser den Zurück-Button des Browser verwenden

...ich bastel gerade an einem Spielchen, und sitze schon seit mehreren Tagen mit einen großem Fragezeichen über dem Kopf vor meinem Code. Ich weiss nicht, wie ich die Klassenstruktur bzw. Aufgabenverteilung gestalten soll, um mein Vorhaben umsetzen zu können, ohne dass es in dilletantischem Code-Chaos endet.

Das Game ist Tetris-/Puzzle-ähnlichs, und mein Problem liegt darin dass ich nicht weiß wie ich die Spielsteine implementieren soll.

Grundsätzlich fallen im Spiel 2-elementige Bausteine herunter, die man bewegen und drehen kann. Die einzelnen Elemente haben verschiedene Farben und es geht natürlich darum das ganze möglichst gut zusammenzubauen. Soweit ist das ja eig. nur Tetris, aber jetzt gibt es halt ein paar Unterschiede.

So ein "Element" ist entweder ein "normales" Element oder eine Bombe. Für den Fall, dass es eine Bombe ist, löst es beim Aufsetzen ein Event aus. (es sprengt alle Elemente, die die gleiche Farbe haben und über einen Weg im Spielbrett mit der Bombe verbunden sind).

Ein steuerbarer Stein besteht eben aus 2 solcher Elemente, das ist zufällig. Es können also 2 normale Elemente sein, 2 Bomben oder 1 Bombe und ein normales Element. Die Farben sind auch random.

Soweit wäre das noch gar nicht so wild, abgesehen vom Event, aber das ist jetzt noch gar nicht mal das Problem. Es kann im Spiel nämlich auch passieren, dass mal NICHT ein solch 2-elementiges Teil droppt, sondern nur ein einziger Stein, der sich auch nicht steuern lässt, und mit hoher Geschwindigkeit einfach ins Spielfeld fällt. Ist er aufgesetzt, wird er für eine gewisse Zeit eine Art "Sperre", d.h. es lässt sich nicht wegsprengen mit einer gleichfarbigen Bombe. Erst nach Ablauf der Zeit verwandelt er sich wieder in einen normalen Stein. Eine Bombe wird übrigens auch ein normaler Stein falls man sie nicht so platziert, dass sie Kontakt zur entsprechenden Farbe hat.

Also das ganze birgt für mich jetzt folgende Probleme:

1) Elemente müssen zur Laufzeit ihren Typ ändern können (von Sperre/Bombe zu normalem Element zB). D.h. ich brauche Komposition. Ich glaube das "Decorator Pattern" wäre hier angesagt?

2) Wie bau ich möglichst schlau zB das Verhalten beim Absetzen eines Elementes ein? ein normaler Stein macht nix weiter beim Absetzen, eine Bombe sprengt etwas..

3) Große Sorgen hab ich auch wenn ich an den GameLoop denke. Man sollte ja die Logik und Animation entsprechend der vergangenen Zeit berechnen, damit es flüssig läuft. Siehe Quaxli's Spiele-Tutorial, da wird ein "delta" benutzt, was einfach die verstrichene Zeit seit dem letzten Loop ist. Jetzt fallen die Elemente ja unterschiedlich schnell, ihre Animation ist verschieden und auch unterschiedlich schnell. Und wie steuer ich wann ein neuer Spielstein kommt? zB wenn gerade etwas explodiert, soll keiner kommen, erst wenn das zu Ende ist.

Also alles in allem hab ich keine Ahnung, wie ich das alles designen soll, sodass ich nicht hunderte von booleans und if-else/switches im Code hab, wo man dann sehr schnell überhaupt nix mehr blickt. So will ich es auch auf keinen Fall machen, weil das bringt ja nix außer hunderte Stunden "vergeudete" Zeit. (Es geht mir im Endeffekt ja nicht ums Spiel, sondern um die Programmier-Erfahrung).

Ich will auch nicht dass es rüberkommt wie "Programmiert mir bitte mein Spiel", es ist ein eigenes Projekt und ich will das ja selber machen. Aber hier versagt einfach mein Design-Wissen / meine Design-Erfahrung.
Ich hab auch das Buch "Design-Pattern von Kopf bis Fuss", also ich würde mich schon riesig freuen wenn ihr mir sagen könnt welche Pattern man hier überhaupt anwenden kann.
...Falls hier irgendjemand eine grobe Struktur im Kopf hat, was für Klassen ich da erstellen könnte, welche abstrakt sind, wo ich Interfaces einsetzen sollte usw.. Das wäre prima.

Ich hock halt echt seit Stunden nur da und starr meinen Code an, und schreibe nicht 1 einzige Zeile, weil ich schon bei jedem Ansatz nach 10 Sekunden überlegen merke, dass das so absoluter Schwachsinn wird :bahnhof:

Danke!!

 

[Spacerat]

Wer sagt eigentlich, das ein Gameloop immer ein konstantes Time-Delta haben muss? So ein Spielablauf wie du ihn vorhast erinnert mehr an eine Schrittkette, die zyklisch abgearbeitet wird.

1. Schritt: Element kreieren
2. Schritt: Element fallenlassen
3. Schritt: Element bewegen
4. Schritt: Element ablegen
5. Schritt: auswerten (sprengen usw.)

Animationen müssen natürlich immer noch getimed werden.

 

[hdi]

Danke erstmal für deine Antwort.

Also entweder ich versteh dich jetzt nicht oder andersrum
Es wird ja nicht immer ein Stein kreiert, bevor man ihn bewegen kann. Ein Stein wird i.d.R. öfters bewegt, bis er abgelegt wird, und erst dann kommt ein neuer Stein. Das Problem ist bei jedem Durchlauf muss ich irgendwie prüfen, ob ein neuer Stein kreiert werden muss, weil zuvor einer "normal" abgelegt wurde, oder ich ich jetzt erstmal ne Explosion starten muss bevor der neue Stein kommt.
Eben dieser Zeitfortschritt in die Logik reinkriegen, das schaff ich nicht. Weil es eben nicht immer gleich ist, sowas wie:

public void doLogics(long delta){
   stein.moveDown(delta);
}

ist es ja nicht. Es ist eher:

public void doLogics(long delta){
   if(stein.hasNotDropped()){
        stein.moveDown(delta);
   }
   else{
        if(shouldMakeExplosion()){
            makeExplosion(delta);
        }
        else if{sperrSteinIncoming()){
            moveDownSperrStein(delta);
        }
        else{
            stein = new Stein();
        }
    }
}

Vllt wird mein Problem so klarer... Wie soll ich auf vernüntige Weise rausfinden können was grad abgeht, diese Methode wird ja alle paar ms aufgerufen, und ich könnte jetzt in den verschiedensten Situationen stecken: Eine Explosion fängt an, oder läuft schon seit 400 ms, oder ich beweg nen Stein runter, oder sonst was..

 

[maki]

1) Elemente müssen zur Laufzeit ihren Typ ändern können (von Sperre/Bombe zu normalem Element zB). D.h. ich brauche Komposition. Ich glaube das "Decorator Pattern" wäre hier angesagt?

2) Wie bau ich möglichst schlau zB das Verhalten beim Absetzen eines Elementes ein? ein normaler Stein macht nix weiter beim Absetzen, eine Bombe sprengt etwas..

Werfe da mal State Pattern und Strategy Pattern ein.

 

[hdi]

Danke maki, das hat mich schon weitergebracht!
Meine Klasse für ein Element sieht jetzt erstmal so aus:

public abstract class Tile {

	private Color color;
	private int x, y;
	private int size;
	private TileState state; // State Pattern
	private DockBehaviour dockBehaviour; // Strategy Pattern

	public abstract void paint(Graphics2D g);

	public void doLogics(long delta) {
		state.process(delta);
	}
}

Der State ist halt eine jeweilig konkrete Implementation, zB "MoveState", "ExplodeState", "DropState" usw. Was die process()-Methode macht ist dann die Position verändern, oder im Falle des Explode-States die Farbe und Größe ändern (fadet aus).

Aber ein Problem habe ich noch immer: Ich muss ja prüfen, ob beim MoveState er das überhaupt darf, also runterbewegen. Sprich wenn ich die Logik im Element selber, sprich dem State, machen will, muss jedes Element alle anderen Elemente im Spielfeld kennen. Und das sollte ja eig. nicht so sein, also OO-mäßig gesehen, oder..

Mein zweites großes Problem ist dass ich nicht weiss wie ich 2-elementige Steine und 1-elementige Steine unter einen Hut bekomme.. Im Spiel droppen von oben jeweils beide Typen zufällig. Ich weiss nicht wie ich die beiden irgendwie zu einer Gemeinsamen Klasse/Interface extrahieren kann. Dafür sind die doch eig. zu unterschiedlich :bahnhof:

 

[EgonOlsen]

Ich hock halt echt seit Stunden nur da und starr meinen Code an, und schreibe nicht 1 einzige Zeile, weil ich schon bei jedem Ansatz nach 10 Sekunden überlegen merke, dass das so absoluter Schwachsinn wird :bahnhof:

Nicht hocken und starren, tippen. Wenn es Käse wird, wieder löschen und von vorne. Dadurch lernt man meiner Ansicht nach mehr, als durch dogmatisches Festhalten an irgendwelchen mehr oder weniger obskuren Pattern, deren einziger Sinn es teilweise ist, Selbstverständlichkeiten einen hochwichtigen Namen zu geben.
Wenn du, wie erwähnt, Kollisionen zwischen den Objekten prüfen willst, dann muss irgendjemand diese Objekte kennen, So ist das eben und daran ist auch überhaupt nichts schlimmes oder nicht-OOiges. Wenn ich z.B. ein Fenster malen will, muss ich wissen welche Knöppe da drin sind.

 

[Spacerat]

Hab' mal zum besseren Verständnis meines 1. Beitrags was ausgearbeitet.

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class SequenceFunctionChart
{
	private final List<Step> steps;
	private int step = 0;

	public SequenceFunctionChart()
	{
		List<Step> steps = new ArrayList<Step>();
		GameContext context = new GameContext();
		steps.add(new Dropper(context));
		steps.add(new Mover(context));
		steps.add(new Analyser(context));
		this.steps = Collections.unmodifiableList(steps);
	}

	public void doLogic(long delta)
	{
		if(steps.get(step).doProcess(delta)) {
			step++;
			step %= steps.size();
		}
	}
}

abstract class Step
{
	protected final GameContext context;

	protected Step(GameContext context)
	{
		this.context = context;
	}

	abstract boolean doProcess(long delta);
}

class Dropper
extends Step
{
	Dropper(GameContext context)
	{
		super(context);
	}

	@Override
	boolean doProcess(long delta)
	{
		return false;
	}
}

class Mover
extends Step
{
	Mover(GameContext context)
	{
		super(context);
	}

	@Override
	boolean doProcess(long delta)
	{
		return false;
	}
}

class Analyser
extends Step
{
	public Analyser(GameContext context)
	{
		super(context);
	}

	@Override
	boolean doProcess(long delta)
	{
		return false;
	}
}

class GameContext
{
	// ...usw.
}

Mit dem boolean von [c]doProcess(long delta)[/c] meldet der aktuelle Schritt, dass er abgearbeitet wurde (Weiterschaltbedingung). Innerhalb eines dieser Schritte weis man als Entwickler, was im Schritt davor geschah, bzw. im aktuellen und folgendem geschehen soll und welcher Schritt wann aktiv ist. Die Schrittklasse selbst benötigt diese Infos nicht. Das einzige was solch ein Schritt benötigt, sind Infos über den Spielkontext.

 

[Metacoder]

Erst mal zu Pattern:
Ich würde Pattern nicht als in Stein gemeißelte Wahrheiten für jedes Problem betrachten.
Nicht die Richtung denken
Ich hab ein Problem -> welches Pattern passt dazu
sondern eher
Ich hab ein Problem -> die Lösung könnte so oder so aussehen -> gibt es ähnliche Pattern oder eben nicht.
Wenn Du einige Pattern verinnerllicht hast, dann fällt Dir "automatisch" ein passendes ein.

Ich bin momentan auch an einem Tetris-Klon dran und beschreib hier einfach mal grob mein vorläufiges Design. Es ist, wie das Spiel selbst, noch nicht ganz ausgereift.
Evtl. kannst Du ja etwas davon wiederverwenden:

Die Puzzlesteine:
Hier hab ich als Model zwei Klassen.
Die Klasse Box repräsentiert ein Kästchen (x,y Koordinaten, Farbe, untere Kante(wichtig bei Kollisionscheck)).
Die Klasse Shape repräsentiert das aus Boxen zusammengesetzte Puzzleteil.
Bewegung/Steuerung:
Die Klasse Box bietet eine Move-Methode, welche die xyKoordinaten der Box ändert.
Die Klasse Shape bietet 3 Move-Methoden (rechts, link, unten), welche den Befehl an seine Boxen delegiert. Bei den Seitwärtsbewegungen wird kontrolliert, ob der nächste Schritt möglich ist (Panelränder erreicht bzw. andere Boxen im weg). Bei der Abwärtsbewegung wird der nächste Schritt auf Kollision einer Box mit einer unteren Kante mit Boden oder einer anderen Box kontrolliert.
Die kontinuierliche Abwärstbewegung wird von einem Timer gesteuert.

Wird eine Kollision ausgelöst, wird die HandleMethode des Listener aufgerufen (ein Controller).
Der Checkt dann z.B. ob komplette Reihen zum Abräumen vorhanden sind (die unteren Reihen komplett mit Boxen gefüllt?). Die Boxen der Shape werden in einer Liste gespeichert. So wird das nun fest sitzende Puzzleteil beim Kollisionhandling und beim Abräumen der Reihen zukünfitig berücksichtigt.
Sind alle Checks durch wird ein neues Puzzleteil erzeugt.

Konfiguriert werden die Puzzleteile als Matrizen, welche dann gespiegelt oder transponiert werden können (rotieren der Teile). Das leistete auch die Shape-Klasse.

Das Ganze wird mit diversen Controllern koordiniert.

 

[maki]

Nicht hocken und starren, tippen. Wenn es Käse wird, wieder löschen und von vorne. Dadurch lernt man meiner Ansicht nach mehr, als durch dogmatisches Festhalten an irgendwelchen mehr oder weniger obskuren Pattern, deren einziger Sinn es teilweise ist, Selbstverständlichkeiten einen hochwichtigen Namen zu geben.

Sehe ich genauso, da sind Tests ein muss, am besten TDD, so ist man sehr flexibel und kommt jederzeit wieder aus einer Sackgasse raus.

Hatte eigentlich gehofft dass jemand nach dem Unterschied zwischen State und Strategy fragt...
Die UML KLassendiagramme sind identisch für die beiden Muster *g*
Im endeffekt ist es polymorphy, am einem bestimmten Ziel ausgerichtet..

 

[Spacerat]

Hatte eigentlich gehofft dass jemand nach dem Unterschied zwischen State und Strategy fragt...

Tja... die Hoffnung stirbt zuletzt... normalerweise. In Sachen Entwicklung sind Designpatterns zwar oftmals hilfreich weil sie im Vorfeld schon einen Lösungsweg beschreiben aber kaum ein Entwickler kann sich alle merken.
Wenn man nun einige DPs nicht kennt, so wie hdi gerade und dann versucht nur die DPs zu verwenden, die man kennt, nur weil man sich an DPs "aufhängen" möchte, hat man ein (bzw. ein zusätzliches) Problem.
DPs sind deswegen erst einmal Nebensache .Vllt. fragte deswegen auch keiner nach dem Unterschied. Mein Beispiel von oben habe ich mir ohne Kenntnis eines passenden DPs aus den Ärmeln geschüttelt. Es besteht nun aber die Möglichkeit, dass ich unwissendlich ein DP verwendet habe, vllt. sogar State oder Strategy aber sollte mich das nun noch interessieren, weil die Lösung nun mal schon dort steht?
@Edit: Sei's drum. Könnte es sein, dass das DP zu meinem Beispiel "SequenceFunctionChart" heisst?

 

[Landei]

Die wichtigesten Pattern, die ein Programmier kennen muss (wenn auch nicht unbedingt mit ihrem lateinischen Namen) sind Antipattern und Bugpattern...

 

[maki]

Es besteht nun aber die Möglichkeit, dass ich unwissendlich ein DP verwendet habe, vllt. sogar State oder Strategy aber sollte mich das nun noch interessieren, weil die Lösung nun mal schon dort steht?

Deswewegen sind die Muster ja wiederkehrende Lösungensmuster für ähnliche Probleme
So 6 - 10 "klassische" DPs zu kennen und vor allem zu erkennen erleichtert die Arbeit manchmal schon sehr.
Den Vorteil den man bekommt wenn man weiss wie sie heissen: Man kann darüber kommunizieren, ohne Code. Neue Entwickler haben es auch einfacher, sofern sie DPs kennen und erkennen

Das jemand der gerade mit DPs "angefangen" hat nun versucht so viele wie möglich ins Design zu quetschen ist auch normal und geht vorbei
DPs sind keine akademische Disziplin, wenn man sauberen Code hat man zwangsläufig auch einige DPs verwendet, selbst ohne sie zu kennen/erkennen. Sie sind eher ein Kommunikationsmittel.

Ich finde TDD einen sehr guten Weg um guten Code herzustellen, oder besser gesagt: Nach ein paar Refactorings endet man mit gutem Code, die erste Version soll ja "nur" laufen..