[Projekt] Matris

[donelik]

[ZFX-Vorwort]

Guten Abend,

es ist soweit: ich möchte ein Projekt realisieren. Ich werde meinen Fortschritt immer in Form eines Entwicklertagebuchs in mein Blog veröffentlichen. Da dort nur Personen aus meinem privaten Umfeld lesen vermute ich kein allzu großes Feedback :) - und genau dort kommt ZFX bzw. ihr "ins Spiel". Ich werde alle Artikel auch hier in diesem Thread veröffentlichen und erwarte konstruktive Diskussionen und kann schnell und einfach auf Fragen reagieren.

Ich sehe dabei vor allem einen großen Vorteil: Ich habe ein Publikum welches ich nicht enttäuschen kann und will. Bisher sind Projektideen von mir im Sande verlaufen und das will ich nicht wiederholen. Desweiteren kann dieser Thread dann als Anlaufstelle für ähnlich gesinnte dienen.

Momentan existiert noch keine Zeile Quelltext oder Ähnliches. In meinem Kopf schwirrt nur eine grobe Idee die ich auch direkt im ersten Eintrag ausformulieren werde.

Ich weiß nicht wie und wann dieses Projekt enden wird aber lade euch trotzdem ein mich auf meiner Reise, zum ersten Release-fähigen Spiel, zu begleiten.

Cheers!

[Edit: Blog-URL angepasst]

[donelik]

Entwicklertagebuch MATRIS #1 - Aller Anfang ist schwer

MATRIS - Kofferwort aus MATRIX und TETRIS (außerdem die schwedische Bezeichnung für Matrix)

Schon längere Zeit wollte ich ein kleines Spiel entwickeln aber ich tat mich schwer eine einzigartige Idee zu finden. So verbrachte ich den Großteil der Zeit damit ein Alleinstellungsmerkmal zu suchen statt das zu tun was ich kann: Programmieren.

Jedem Anfänger wird empfohlen zunächst eine etablierte Spielidee nachzubauen und sogar zu erweitern. Genau das werde ich tun. Ich werde einfach DIE Idee der 80er nehmen und erweitern.

Idee: Ein dreidimensionales quadratisches Areal (ein Würfel) welches von allen 6 Seiten mit Blöcken befüllt wird. Blöcke bewegen sich immer nur an einer der drei Achsen auf den Nullpunkt zu. Am Nullpunkt selbst befindet sich eine Fläche die kein Block passieren darf. Sobald Blöcke eine durchgehende Fläche durch das Areal bilden löst sich diese Fläche auf so das nachfolgende Blöcke nachrutschen können. Nachrutschende Blöcke bewegen sich auch nur auf der Achse auf der die Fläche aufgelöst wurde. Sobald ein aufsetzender Block die äusseren Grenzen des Areals “überlappen” gilt das Spiel als verloren. Blöcke bestehen aus einen oder mehrere Würfeln. Blöcke ausserhalb des Würfels sind auswählbar, steuerbar und rotierbar.

Diese Idee hat sich in der letzen Minuten bereits gewandelt. Ursprünglich wollte ich Blöcke, die eine Linie bilden, auflösen. Leider würde es da zu Konflikten bei nachrutschenden Blöcken kommen. Diese Konflikte konnte ich nicht auflösen so dass für den Spieler ersichtlich ist warum dieser Block vorrang beim Nachrutschen bekommt statt der andere. Ein Freund empfahl keine Linien aufzulösen sondern nur gesamte Flächen - so können Blöcke nur in eine Richtung nachrutschen.

Bevor ich mir jetzt weitere Gedanken über Punktesystem, Spielmodi usw. mache baue ich einen Prototyp um zu Überprüfen ob die Idee erstmal so läuft und auch Spaß machen könnte - ich vermute wieder Konflikte wenn gleichzeitig zwei Flächen auf zwei Achsen aufgelöst werden und Blöcke nachrutschen können.

Für den Prototyp verwende ich Unity 4.1.5 mit JavaScript. Folgender Funktionsumfang wird implementiert:

• drei Formen von Blöcke
• Blöcke fallen auf allen Achsen und sind anklickbar, steuerbar und rotierbar
• mit Blöcken befüllte Flächen lösen sich auf

[Edit: Titellink angepasst; Bild-URL angepasst; Bild auf ZFX geladen]

[joeydee]

Dann halt uns mal auf dem Laufenden mit dem Prototypen.
Soweit ich mich erinnern kann, gabs bei den früheren 3D-Tetris-Varianten 2 Hauptprobleme:
- Das Rotieren um mehrere Achsen kann man sich schwer merken/vorhersehen; der Block drehte sich meistens so wie man es nicht wollte;
- es werden immer Zellen verdeckt, d.h. man sieht nicht ob eine Ebene gefüllt ist oder nicht bzw. welche Stelle fehlt.

Würde mich interessieren, ob diese Probleme bei dir ebenfalls auftauchen, oder ob du elegante Lösungsansätze dafür hast.

[donelik]

Entwicklertagebuch MATRIS #2 – Der Prototyp

Die Idee mit dem Würfel der von allen sechs Seiten mit Blöcken bombardiert wird ist gestorben. Die Konflikte (welcher Block darf rutschen und wohin) konnte ich auch durch den Prototypen nicht lösen. Also nun doch das klassische Tetris bei dem ein Rechteck von oben mit Blöcken befüllt wird.

Da ich mich etwas mit der dahinterliegenden Geometrie beschäftigt habe, bemühe ich mich ab jetzt die korrekten Begriffe zu verwenden. Bei den Blöcken handelt es sich um Polywürfel.

Das klingt doch nach was: Polywürfel! Ein Würfel ist das kleinste Spielobjekt. Durch das kombinieren von Würfel kann ein komplexeres Spielobjekt, der Polywürfel, geschaffen werden. Danke, Wikipedia!

Ich habe für den Prototypen etwa zehn Stunden gebraucht wobei die meiste Zeit für das Rotieren der Polywürfel drauf gegangen ist. Dank Unity und den Gizmos konnte ich mich auf die Logik konzentrieren statt Zeit in das Visuelle investieren zu müssen. Deswegen stammen alle Screenshots aus dem Scene-Fenster.

Ich habe drei Klassen implementiert: Grid.js, Game.js, Pattern.js.

Das Game übernimmt die Aufgabe des Taktgebers. Nach dem Ablauf einer definierten Zeitspanne findet ein Tick statt und der momentan aktive Polywürfel bewegt sich eine Einheit nach unten. Die Klasse nimmt außerdem Eingaben des Benutzers entgegen und leitet diese an die entsprechenden Stellen weiter. “WASD” rotiert die Polywürfel, die Pfeiltasten Bewegen die Polywürfel auf der aktuellen XZ-Ebene und die Leertaste leitet unmittelbar den nächsten Tick ein. Zum Debugging habe ich auch Funktionalität implementiert die nicht im fertigen Spiel landet: PageUP bewegt Würfel wieder nach oben.

Das Grid ist eine dreidimensionale Bitmaske die Auskunft darüber gibt welches Tile (=Kachel) mit einem Block belegt ist. Ich nutze diese Klasse für die Darstellung des Levels und auch für die Darstellung des aktuellen Polywürfels. Es wird definiert durch eine Halbbreite, Halbhöhe, und Halbtiefe. Weil ich die Konfiguration auf Halbwerte beschränke ist es leicht möglich stets einen Mittelpunkt zu haben.

Code: Alles auswählen

myWidth = 1 + (this.halfWidth*2);
myDepth = 1 + (this.halfDepth*2);
myHeight = 1 + (this.halfHeight*2);
myTiles = new boolean[myWidth, myHeight, myDepth];

Diesen Mittelpunkt nutze ich im Level als Spawn-Punkt für herunterfallende Polywürfel und auch als Anker für das Rotieren.

Wie schon oben beschrieben hatte ich Probleme mit dem Rotieren. Ich habe sehr viel Zeilen Code verworfen, neu geschrieben und wieder verworfen. Irgendwann habe ich dann auf einem Papier skizziert was ich eigentlich will. Dort konnte ich auf einem Blick erkennen wo welcher Würfel hin wandert und welche Schleifen dazu benötigt werden.

Ich vermute gerade beim Rotieren noch viel Verbesserungspotential – aber: PROTOTYP :) .

Ein Pattern ist ein Boolesches-Array welches mir ermöglicht im Unity Inspector neue Polywürfel zu entwerfen. So habe ich mein Prototyp-Ziel “drei Formen von Blöcke” mehr als erreicht :) .

Hier fehlt noch die Validierung ob es sich bei dem Pattern um einen validen Polywürfel handelt – das habe ich aber, so wie viele andere Sachen, im Prototyp vernachlässigt.

Das Spiel startet mit einem leeren Grid. Am höchsten Mittelpunkt spawnt immer ein zufälliger Polywürfel sobald es keinen aktiven Polywürfel mehr gibt. Ich schaue in jeder Frame ob der Spieler den Polywürfel drehen oder bewegen will. Wenn eine Eingabe kommt überprüfe ich zunächst ob der Polywürfel an der neuen Stelle mit der neuen Rotation entsprechend Platz hat. Dazu iteriere ich einfach alle Würfel durch und schau ob sie noch im Grid sind oder ob sie einen bereits belegten Platz besetzen wollen.

Code: Alles auswählen

/* schnipp ...*/
 
// Grenzen überprüfen
if(!IsTileWithinGrid(check.x, check.y, check.z))
{
    return false;
}
 
// Andere Blöcke überprüfen
if(IsTileOccupied(check.x, check.y, check.z))
{
    return false;
}
 
/* ... schnapp */

Sollte hier “false” geliefert werden, wird keine Bewegung oder Rotation durchgeführt. Als “gelandet” gelten Polywürfel erst wenn keine Bewegung nach unten möglich ist. Genau in diesem Moment wird überprüft ob der Polywürfel die oberen Grid-Grenzen übertritt. Bei Übertretung ist das Spiel beendet. Wenn alles im Rahmen bleibt wird der aktive Polywürfel vom Level-Grid absorbiert. Erst nach einer Absorbierung schaue ich, ob es komplett gefüllte XZ-Ebenen gibt. Wenn ja, werden diese als nicht besetzt markiert und alle Ebenen drüber rutschen runter. Zum Schluss wird noch überprüft ob es Würfel(-ketten) ohne direkten oder indirekten (Nachbarn, Nachbarsnachbarn, …) Kontakt zum Boden gibt – diese fallen dann solange nach unten bis der Boden oder ein anderer besetzter Tile den Weg versperrt.

Dank des Prototypen habe ich nun eine ungefähre Ahnung wie ich mein Ziel erreiche. Während der Implementierung musste ich mich oft dran erinnern dass dies nur ein Prototyp ist der nur mögliche Probleme aufzeigen soll. joeydee hat die 2 Hauptprobleme schon genannt:

• intuitive Rotation schwer möglich
• verdeckte Lücken

Wobei man die verdeckten Lücken auch als Gameplay-Element behandeln kann: Macht das ganze etwas kniffliger. Nicht sichtbare Lücken könnten z.B. farbig pulsieren oder neben dem eigentlichen Level-Grid wird ein Lücken-Grid angezeigt in dem nur Tiles angezeigt werden die man, egal wie man die Kamera rotiert, nie zu Gesicht bekommen würde.

Für die Rotation schwirrt mir auch schon eine Idee im Kopf. Zunächst einmal hat jeder Polywürfel sowieso einen definierten Mittelpunkt der als Rotationsanker dient. Diesen könnte ich auch farblich hervorheben. Je nachdem auf welche Seite des Mittelpunkts die Kamera gerade schaut werden anderen Achsen rotiert (ich schau von oben drauf -> Y-Achse wird rotiert …) – genauso auch für das Bewegen der Würfel. Dies kann ich erreichen durch ein Frustum für jede Würfelseite.

Da diese zwei Probleme das Projekt nicht behindern, kann ich ohne Umwege weitermachen.

Fazit des Prototyps:

• Ich bleibe bei Unity
• Ich liebe Gizmos
• Prototyping ist sehr nützlich
• Prototyp sollte für Debug-Zwecke unübliche Spielzüge erlauben

Zum jetzigen Zeitpunkt kann ich folgende Meilensteine festlegen:

1. Gameplay weitestgehend festziehen und ausformulieren
2. Gameplay implementieren
3. Grafik hübschen (Effekte, Farben, Umgebung)
4. Nachbessern

Ich leide mittlerweile unter dem Tetris-Effekt.

[Edit: Titellink angepasst; Meilenstein-Liste sortiert; Bilder auf ZFX geladen]

[Top-OR]

Ich leide mittlerweile unter dem Tetris-Effekt.

Oh Gott, da gibts WIRKLICH nen Namen für?
Ich kenne das Phänomen aus den ersten Tagen meines "gemeinsamen Lebens mit dem Computer" - ist so ca. 22 Jahre her: Eins der GANZ wenigen Spiele, die da drauf liefen, war "Lode Runner" (http://www.heise.de/software/screenshots/g11569.gif) , was ich exzessiv gezockt habe. Nach ner Weile habe ich davon geträumt: Das war echt ein seltsamer Trip: Gut zu wissen, dass es den Effekt "wirklich" gibt... ;-)

Um frei nach "Dr. Sheldon Cooper" zu zitieren das Ganze im Nachhinein betrachtet: "Ich (war also) nicht verrückt, meine Mutter hat mich testen lassen!" :-D

[donelik]

Entwicklertagebuch MATRIS #3 – Das Gameplay und das GUI

Ein paar Stunden in die Konzeptionierung gesteckt und schon ist ein, wie ich finde, stimmiges Gameplay für die erste Version entstanden. Besonders hilfreich war hierbei das Austreichen von Punkten die zu komplex für den ersten Wurf werden - diese hebe ich mir für eine Version zwei auf :).

Steuerung
Mit der Maus kann man um das Grid rotieren und mit dem Mausrad kann man ran- und rauszoomen. Die WASD-Tasten bewegen den aktuellen Polywürfel im Grid auf der XZ-Ebene. Den Polywürfel rotieren kann der Spieler mit der rechten und linken Maustaste. Rotiert wird die Achse auf der der Spieler gerade schaut (die rechte Maustaste dreht den Polywürfel immer nach "rechts" aus der aktuellen Perspektive). Die Tasten 1,2 und 3 werden mit Power-ups belegt.

Schwierigkeitsfaktor
Das Spiel startet mit einem Schwierigkeitsfaktor 1 der mit der Zeit ansteigt. Zunächst strebe ich eine Zeitspanne von zehn Sekunden für jede Schwierigkeitsstufe an.

Tickdauer
Beschreibt wieviel Sekunden es dauert bis ein Tick vergeht. Die Zeitspanne berechnet sich wie folgt:

Tickdauer = TickdauerStart * ( TickdauerVerringerung ^ ( Schwierigkeitsfaktor - 1) )

Beispiel: TickdauerStart=2 und TickdauerVerringerung=0,75
Schwierigkeitsfaktor => Tickdauer in Sekunden
1 => 2
2 => 1.5
3 => 1.125
4 => 0.84375

Würfel
Jeder Polywürfeln hat eine von drei Farben. Beim Auflösen einer oder mehrerer Ebenen werden die jeweiligen Farben gezählt. Die Farbe mit dem höchsten Zähler wird auf ein Farbkonto gutgeschrieben von dem aus man Power-ups bezahlen kann.

• rot
• blau
• grün

Nächste Polywürfel
Der Spieler kann stets die drei nächsten Polywürfel sehen.

Power-ups
Mit Farbpunkten kann man Power-ups kaufen die dem Spieler eine kurzweilige Erleichterung verschaffen.

Power-up: Tickdauerverlängerung

• kaufbar durch rote Farbpunkte
• erhöht für eine Zeitspanne von fünf Sekunden die momentane Tickdauer auf den Wert von TickdauerStart
• Kann erst nach 60 Sekunden wieder gekauft werden

Power-up: Polywürfelauswahl

• kaufbar durch grüne Farbpunkte
• der Spieler kann aus allen verfügbaren Polywürfel einen auswählen der als unmittelbar nächster in der "Nächste Polywürfel"-Liste erscheint
• kann erst nach 60 Sekunden wieder gekauft werden

Power-up: Ebenenvernichter

• kaufbar durch blaue Farbpunkte
• der Spieler kann nach dem Kauf eine Ebene auswählen die aufgelöst werden soll
• kann erst nach 60 Sekunden wieder gekauft werden

Die Kosten für ein Power-up kann ich absolut nicht abschätzen. Deswegen werde ich diese erstmal auf 10 festlegen. Hier spielen ja auch andere Faktoren wie Grid-Breite und -Tiefe eine Rolle. Wenn ich merke dass ein Power-Up zu mächtig wird muss ich auch deswegen den Preis hochschrauben.

Online-Highscore
Der Spieler hat nach einer verlorenen Runde (man kann nur verlieren - die Frage ist wielange das dauert ;) ) die Möglichkeit seinen Punktestand auf meinen Server zu übertragen. Dafür ist nur ein freiwählbarer Name erforderlich.

Punkte
Die Punkte innerhalb eines Ticks werden wie folgt berechnet:
Punkte = (Anzahl der aufgelösten Würfel) * (Anzahl der aufgelösten Ebenen) * (Schwierigkeitsfaktor)

Damit ist die Anzahl der aufgelösten Ebenen ein Punktemultiplikator. Die Tick-Punkte werden zur Gesamtpunktzahl addiert.

Mutation
Von unten spawnen, nach einer vom Schwierigkeitsfaktor abhängigen Zeitspanne, Ebenen mit zufällig belegten Tiles und Farben. Die Zeitspanne dazu sollte meines Erachtens von der Grid-Höhe abhängen weil der Spieler sonst unter Umständen nicht hinterkommt. Deswegen werde ich mit dem fine tuning bis nach der Implementierung warten und den Wert zunächst auf fünf Sekunden setzen.

Aus diesen Gameplay-Elementen ergeben sich folgende Spielmodi:

Modus = SSF,SFA,Power-ups,Mutation,Online-Highscore
Klassisch = 1,true,false,false,true
Klassisch+ = 1,true,true,false,true
Mutation = 1,true,false,true,true
Mutation+ = 1,true,true,true,true
Selbsterstellt = konfigurierbar,konfigurierbar,konfigurierbar,konfigurierbar,false

SSF=Startschwierigkeitsfaktor; SFA=Schwierigkeitsfaktoranstieg

Graphical User Interface (GUI)

Während die Views Hauptmenü, Highscore, Selbst erstellen und Game over wohl selbsterklärend sind, will ich beim Spiel-View etwas ausholen.

Die Kästchen links mit dem irreführenden Inhalt "100x100" stellen die nächsten Polywürfel dar. Drunter steht der aktuelle Schwierigkeitsfaktor und die verbleibende Zeit bis zum nächsthöheren Schwierigkeitsfaktor. Oben rechts in schwarz ist die momentane Gesamtpunktzahl und drunter die jeweiligen Farbkonten. Unten rechts sieht man die Kosten für das jeweilige Power-up und den momentanen Abkühlstatus. Dieser View ist also wirklich nur eine View und bietet keine anklickbaren Knöpfe oder Ähnliches.

Fazit
Im GUI zeige ich nur die Daten an, die für das Gameplay direkt relevant sind - hier wird natürlich noch viel passieren aber zum jetzigen Zeitpunkt genügen diese spartanischen Sichten.

Die meisten fixen Werte kann ich noch gar nicht richtig einschätzen und werden wohl erst festgesetzt sobald man das Spiel spielen kann - Balancing.

Damit wäre der ersten Meilenstein erreicht: Ein implementierfähiges Konzept steht. Ich sehe momentan keine Blocker oder Probleme die ich nicht schon im Prototypen gelöst habe. Fein.

Einen großen Punkt im Meilensteinplan habe ich vergessen: Audio. Deshalb hier der aktuelle Plan:

• Gameplay weitestgehend festziehen und ausformulieren
• Gameplay implementieren
• Audiovisuelles Feedback aufhübschen (Effekte, Farben, Umgebung, GUI)
• Nachbessern (Bugs, Balancing)

Hätte ich dieses Wiki nur eher gefunden ...

[Edit: Bilder angepasst]