Quelle des Artikels: csdn Autor: Chen Wanfei
Über den Autor
Chen Wanfei, männlich, hat einen Bachelor-Abschluss in Mathematik und Software von der Central South University. Er war leitender Programmierer und Systemanalyst bei Beijing Great Wall Software. Er verfügt über umfangreiche Erfahrung in der J2SE- und J2EE-Entwicklung. Derzeit arbeite ich an der J2ME-Forschung. Er kann unter [email protected] kontaktiert werden
Zusammenfassung
Dieser Artikel enthält einen Entwurfsplan für ein Tetris-Spiel auf Basis von MIDP1.0 und den vollständigen Quellcode für die Implementierung. Das größte Merkmal des Spiels ist die Bildschirmanpassungsfähigkeit. Unabhängig von der Bildschirmgröße verschiedener Mobiltelefone und PDAs kann das Spiel immer den besten Anzeigeeffekt erzielen. Das Spiel wurde auf vier Emulatoren des J2me Wireless Toolkit 2.1 getestet.
Haftungsausschluss: Dieser Spielcode stammt ursprünglich aus einem japanischen Open-Source-Projekt (siehe Referenz 1) und wurde vom Autor erheblich geändert.
Hier sind einige Screenshots des Spiels:
Design
1. Betriebsablauf
Der Bedienungsprozess dieses Spiels ist sehr einfach. Nachdem der Benutzer das MIDlet gestartet hat, gelangt er zum Hauptbildschirm des Spiels und der Bildschirm beginnt mit der Anzeige des Begrüßungsbildschirms. Nachdem der Benutzer die Taste [Start] gedrückt hat, kann er mit dem Spielen beginnen. Wenn der Benutzer die Taste [Start] erneut drücken möchte, wird das Spiel angehalten pausiert, das Spiel läuft weiter. Jedes Mal, wenn die Schaltfläche [Beenden] gedrückt wird, wird das Spiel-MIDlet beendet.
Das Flussdiagramm des Spielbildschirms sieht wie folgt aus:
2. Algorithmus
Das MIDP-Spieldesign verwendet im Wesentlichen einen Thread oder Timer, um Neuzeichnungsereignisse zu generieren, und verwendet Threads und Benutzereingaben, um den Spielstatus zu ändern. Dieses Spiel ist keine Ausnahme. Nach dem Start von MIDlet wird sofort ein Redraw-Thread generiert, der den Bildschirm alle 50 ms zeichnet. Natürlich gibt es beim Neuzeichnen einige Optimierungsmaßnahmen. Nicht alle Pixel auf dem Bildschirm müssen neu gezeichnet werden, aber es gibt Auswahlmöglichkeiten, z. B. die auf der Spielleinwand fixierten fallenden Objekte (insgesamt gibt es 7 Arten fallender Objekte). , bestehend aus 4 kleinen Steinen, jedes fallende Objekt hat eine feste Farbe und kann nach oben, unten, links und rechts gedreht werden, sodass es nicht neu gezeichnet werden muss. Die Spielfläche ist ein CommandListener, der Tastaturbefehle des Benutzers akzeptieren und die Links-, Rechts-, Abwärts- und Rotationsaktionen des fallenden Objekts steuern kann. Die Flusskontrolle des gesamten Spiels spiegelt sich in der paint()-Methode des Game-Canvas-Objekts wider. paint() zeichnet den aktuellen Spielbildschirm basierend auf dem aktuellen Spielstatus. Der Begrüßungsbildschirm und der Game Over-Bildschirm sind recht einfach zu zeichnen. Das Zeichnen des Spielpausenbildschirms ist ebenfalls recht einfach. Setzen Sie einfach ein Flag, sodass bei der Ausführung von paint() keine Neuzeichnungsaktion erforderlich ist. Um den Bildschirm während des Spiels zu zeichnen, muss das fallende Objekt an der aktuellen Position des fallenden Objekts gezeichnet werden. Stellen Sie vor dem Zeichnen des fallenden Objekts fest, ob es noch fallen kann. Lassen Sie es ein Feld fallen und zeichnen Sie es dann. Wenn das fallende Objekt nicht mehr fallen kann, stellen Sie fest, ob das Spiel beendet ist Es befindet sich im Spiel. Wenn sich das Spiel im Status „Über“ befindet, setzen Sie den Spielstatus auf den Status „Spiel beendet“, damit die Leinwand beim nächsten Neuzeichnen den Bildschirm „Spiel beendet“ zeichnet, wenn sich das Spiel nicht im Status „Spiel beendet“ befindet , Im Over-Zustand wird das fallende Objekt fixiert und gleichzeitig werden alle Zeilen unterhalb der aktuellen Zeile des fallenden Objekts auf der Spielfläche überprüft, um festzustellen, ob eine Zeilenlöschung erforderlich ist Die gelöschte Zeile auf der Spielkarte wird gelöscht und anschließend werden die gelöschten Zeilen mit der Hintergrundfarbe gezeichnet. Initialisieren Sie dann ein neues fallendes Objekt und zeichnen Sie dieses neue fallende Objekt. Das Flussdiagramm der Malmethode lautet wie folgt:
3. Datenstruktur
Dieses Spiel beinhaltet die folgenden Datenstrukturen.
Spielbereich
Die Spielfläche ist ein Teil des Mobiltelefon- oder PDA-Bildschirms. Die Fläche ist ein Quadrat und die Seitenlänge muss gleichmäßig durch 16 teilbar sein (da die russische Spielfläche genau ein Quadrat ist, das 16 kleine Steine lang und 16 kleine Steine groß ist). breit). Dieser Bereich sollte sowohl horizontal als auch vertikal zentriert auf dem Bildschirm sein. Der Spielbereich ist horizontal in zwei Teile unterteilt, ein Teil ist 12 kleine Steine breit, um den Spielbehälter anzuzeigen, und der andere Teil ist 4 kleine Steine breit, um das nächste fallende Objekt und die nächste Punktzahl anzuzeigen.
kleine Ziegelsteine
Kleine Steine sind Teil des Drop- und Game-Containers. Erscheint als Quadrat, dessen Seitenlänge 1/16 der Seitenlänge des Spielbereichs beträgt. Wenn jeder kleine Stein gezeichnet wird, bleibt 1 Pixel auf den vier Seiten übrig und wird in Weiß oder Grau gezeichnet, sodass zwischen den Steinen eine Lücke entsteht. Jeder kleine Stein hat auch eine ID, die von 1 bis 8 reicht. Wir können ein Farbarray (im Programm BRICK_COLORS genannt) verwenden, um diese 8 Farben zu speichern. Wenn die ID eines bestimmten kleinen Ziegelsteins 3 ist, ist die Farbe des kleinen Ziegelsteins BRICK_COLORS[3-1].
fallender Gegenstand
Der Tropfen ist im Wesentlichen ein Quadrat aus 16 kleinen Steinen. Es gibt insgesamt 7 Arten fallender Objekte, z. B. solche in Form eines „Feldes“, in Form eines „L“ usw. Für jedes fallende Objekt gibt es 4 Rotationsvarianten. Jedes fallende Objekt hat eine ID zwischen 1 und 7. Denn bei einem fallenden Objekt ist seine Farbe festgelegt. Wir können auch den tiefgestellten Wert dieser Farbe im Array BRICK_COLORS plus 1 als ID des fallenden Objekts verwenden.
Beispielsweise hat das „L“-förmige fallende Objekt die ID 3 und seine Variation ist:
Welche Datenstruktur wird also zum Speichern eines fallenden Objekts verwendet? Nehmen wir zur Veranschaulichung ein „L“-förmiges fallendes Objekt:
Da jedes fallende Objekt vier Zustände hat, können wir erwägen, ein Array der Länge 4 zu verwenden, um die vier Zustände eines fallenden Objekts zu speichern. Jedes Element im Array repräsentiert einen Zustand des fallenden Objekts. Was sollte also verwendet werden, um einen bestimmten Zustand eines fallenden Objekts darzustellen? Wie aus der obigen Abbildung ersichtlich ist, ist es am besten, ein zweidimensionales 4X4-Array zu verwenden, um den Zustand eines fallenden Objekts zu speichern. Wo farbige Steine erscheinen, ist der Wert 1, und wo nur Hintergrundfarbe vorhanden ist und kein Zeichnen erforderlich ist, ist der Wert 0. Daher können die vier Zustände des gesamten „L“-förmigen fallenden Objekts durch ein dreidimensionales Array dargestellt werden:
protected int blockpattern3[][][] = {
{{0, 1, 0, 0}, {0, 1, 0, 0}, {0, 1, 1, 0}, {0, 0, 0, 0}},
{{0, 0, 0, 0}, {0, 1, 1, 1}, {0, 1, 0, 0}, {0, 0, 0, 0}},
{{0, 0, 0, 0}, {0, 1, 1, 0}, {0, 0, 1, 0}, {0, 0, 1, 0}},
{{0, 0, 0, 0}, {0, 0, 1, 0}, {1, 1, 1, 0}, {0, 0, 0, 0}}
};Spielkarte
Die Spielkarte dient zur Aufbewahrung fester Spielsteine auf dem Spielcontainer. Der Spielbehälter ist 12 kleine Ziegeleinheiten breit und 16 kleine Ziegeleinheiten hoch, einschließlich der beiden linken und rechten Wände und des Bodens des Behälters darunter. Daher wird ein zweidimensionales 16x12-Array (im Programm Mapdata genannt) zum Speichern fester Bausteine verwendet. Wenn Mapdata[i][j]=k(k!=0), bedeutet dies, dass sich in Zeile i und Spalte j des Spielcontainers ein fester kleiner Stein befindet und der Farbwert des kleinen Steins BRICK_COLORS[k ist -1]. Wenn k=0, bedeutet dies, dass in Zeile i und Spalte j keine Steine vorhanden sind.
Daher beträgt der Wert der Kartendaten für die folgende Spiellaufzeit {{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0 , 0,0,0,0,0,0,8}{8,0,0,0,0,0 ,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0 ,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8}
{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0,8} {}{8,0,0,0,0,0,0,0,0,0,0,8}{8,0,0,0,0,0,0,0,0,0,0, 8}
{8,0,0,0,0,0,0,0,0,1,1,8}{8,0,0,0,0,0,0,0,0,1,1,8} {8,0,0,0,0,0,7,7,5,1,1,8}{8,0,5,0,0,7,2,5,5,1,1,8}
{8,8,8,8,8,8,8,8,8,8,8,8}}
Quellcode und ausführbarer Code
Insgesamt gibt es 3 Dateien: src.rar, ketrisgame.jad, ketrisgame.jar Hinweis: src.rar enthält alle Quellcodes. Es gibt auch Ressourcendateien, die für die Ausführung des Programms in ketrisgame.jar erforderlich sind. Nach der Installation von wtk2.1 legen Sie ketrisgame.jad und ketrisgame.jar im selben Verzeichnis ab (beachten Sie, dass der Verzeichnispfad keine chinesischen Zeichen und Leerzeichen enthalten darf) und doppelklicken Sie auf ketrisgame.jad Datei, Sie können das Spiel im Emulator ausführen.
Referenzen
http://www.javadrive.jp/j2me/game/3/index.html
<j2me auf den Punkt gebracht>
<Einführung in die Java-Programmierung für Mobiltelefone/PDAs>