Wie schon in den vorigen Kursteilen angekündigt werden Sie nun lernen, wie man ein vollständiges PacMan-Spiel auf Visual Basic schreiben kann. Dafür werden wir die folgenden, bereits besprochenen, Module einsetzen:

Die Sprite-Routinen aus dem letzten Teil sind ein wichtiger Bestandteil des Spieles. Daher kommt – bevor wir mit dem Spiel anfangen – ein kleines Programm, dass die Funktion dieser Routinen veranschaulicht.

Erstellen Sie bitte als erstes ein neues Projekt, und fügen Sie nun die folgenden Dateien hinzu (diese finden Sie im Archiv dieses Kurses bzw. die MCI-Datei im WINDOWS\SYSTEM-Verzeichnis auf Ihrer Festplatte ):

Gleich etwas wichtiges zu Anfang: Wenn Sie mit einer 32-Bit-VB-Version arbeiten, so dürfen die Module nie die Namen tragen, die in dem Modul als Datentypen, Prozeduren oder Variablen verwendet werden! Setzen Sie die Name-Eigenschaft vom Modul SPRITE.BAS nicht auf SPRITE sondern ändern Sie diese in MODUL_SPRITE. Ansonsten gibt Visual Basic beim Startversuch Fehler aus!

Öffnen Sie nun die noch leere Form "Form1". Setzen Sie auf diese ein Bildfeld mit dem Namen Display, und setzen Sie die Eigenschaft AutoRedraw auf "True" und ScaleMode auf "3 - Pixel".

Plazieren Sie das Bildfeld möglichst in der Mitte der Form, da wir in diesem Beispiel keine anderen Steuerelemente verwenden. Wenn der Benutzer später mit der Maus auf diese Bildfeld klickt soll an der Stelle ein kleiner Sprite angezeigt werden

In diesem Programm wollen wir die Funktion SPRITE_SET_MESH benutzen um über einen Befehl eine ganze Reihe von Sprites zu erstellen. Diese Funktion wird aufgerufen mit:

Gibt den Index im Datenfeld an, ab der die Sprites erstellt werden sollen.
In unserem Beispiel verwenden wir hier 0, damit der erste erstelle Sprite den Eintrag 0 bekommt, der zweite den Eintrag 1 usw.

Um die Geschichte mit den Kästchen noch zu verdeutlichen, kommt hier eine kurze Erläuterung. Die Routine SPRITE_SET_MESH geht davon aus, dass das Bildfeld in rechteckige Kästchens aufgeteilt ist. Jedes Kästchen enthält einen Sprite. Um nun aus diesen Kästchen einzelne Sprites zu machen, die man dann einfach über eine Nummer anspricht, benötigt die Routine ein Datenfeld, in dass die Sprites kommen. Außerdem muss die Routine noch wissen, wie viele Kästchen sich auf dem Bild befinden und wie groß die einzelnen Kästchen sind.

In dem Bild oben sehen Sie, wie aus 4 x 3 Rechtecken zwölf neue Sprites entstehen. Die Kästchen müssen übrigens durch Linien voneinander getrennt werden. W und H geben nämlich nur die Ausdehnung des eigentlichen Sprites (innerhalb der roten Umrandung) an. Bei diesem Beispiel muss X = 4 und Y = 3 sein, damit aus allen Kästchen Sprites entstehen. Die Kästchen in diesem Kurs haben immer die Größe 20 x 20 Pixel. Damit müsste der Aufruf für die obige Situation lauten:

Anschließend sind die Einträge 0 - 11 des Datenfeldes Spr() mit den Sprites aus dem Bild belegt. Daran sehen Sie, wie effektiv sich diese Routine einsetzen lässt.

Nun müssen wir aber für unser Beispiel-Programm erst das Datenfeld definieren. Öffnen Sie dazu die Prozedur "(allgemein) / (Deklarationen)" der Form.

In der ersten Zeile definieren wir die Variable PFAD$, die, wie schon im vorletzten Teil, angibt, wo sich die Daten des Programms befinden. In der zweiten Zeile wird unser Sprite-Datenfeld definiert, dass alle Sprites aufnimmt, die wir benutzen werden.

Jetzt kommt die Ereignisprozedur FORM_LOAD.

Zuerst setzen wir unsere Variable PFAD$, so dass VB alle Dateien finden kann, die zu dem Spiel gehören. Hier müssen Sie den Pfad auf Ihrer Festplatte eintragen. Befinden sich die Dateien beispielsweise im Verzeichnis "C:\VBKURS\SPIELE3\DEMO\" so setzen Sie auch die PFAD$-Variable auf dieses Verzeichnis. Wenn Sie später eine EXE-Datei erstellen, müssen Sie PFAD$="" schreiben, damit die Dateien im aktuellen Verzeichnis gesucht werden.

Nun werden die Bilder geladen. Dazu wird mit der Funktion RES_NEW() erst eine neue Ressource erstellt, die das Bild aufnehmen soll. Den Rückgabewert sichern wir in der Variable B1 (der Name ist abgeleitet von Bitmap 1). Danach folgt ein Doppelpunkt. Dieser trennt zwei Anweisungen und ermöglicht es, mehrere Befehle in eine Zeile zu schreiben. Beispiel:

     A=10
     B=5
 
entspricht
 
     A=10: B=5

Anschließend wird mit dem Befehl RES_LOAD das Bild BIT\TEST.BMP in die Ressource mit der Nummer B1 geladen. Das gleiche Spielchen wiederholen wir mit der Variable M1 (abgeleitet von Maske 1) und der Datei MASKE\TEST.BMP. Nun haben wir zwei Bitmaps geladen, die eine enthält die Bitmapdaten, die andere die Maske.

Die Bilder sind wieder in Kästchen aufgeteilt, wobei ein Kästchen innen 20*20 Pixel groß ist. Uns interessiert nur ein Bereich von 8 Kästchen Länge und drei Kästchen Höhe:

An SPRITE_SET_MESH übergeben wir als erstes das Datenfeld Spr(), daß wir definiert haben. Anschließend übergeben wir die Anzahl der Kästchen in X-Richtung (in diesem Fall 8, wie man an dem Bild oben sehen kann) und in Y-Richtung (3 Kästchen). Anschließend folgt die innere Breite und Höhe eines Kästchens in Pixeln. Nun müssen wir die Bildfelder übergeben, in denen die Bilder für die Bitmapdaten und für die Maske sind.

Jetzt fehlt nur noch das Ende der Prozedur:

Damit hätten wir das schwerste dieses Beispiels hinter uns. Die Sprites befinden sich nun in dem Datenfeld Spr() und können mit der Prozedur SPRITE_DRAW ausgegeben werden. In diesem Beispiel soll jeweils ein zufälliger Sprite ausgegeben werden, wenn der Benutzer auf das Bildfeld klickt. Dazu benutzen wir die Ereignisprozedur DISPLAY_MOUSEDOWN.

Der Ereignisprozedur MOUSEDOWN werden einige wichtige und vor allem nützliche Parameter übergeben: Button enthält den Status der Mausknöpfe. 1 steht hierbei für die linke Maustaste, 2 für die rechte und 3 für beide. Shift gibt an, ob die Umschalttaste gedrückt ist (=1) oder nicht (=0). X und Y geben die Mausposition relativ zur oberen, linken Ecke des Bildfeldes an.

In der zweiten Zeile wird die Prozedur SPRITE_DRAW aufgerufen. Als erstes übergeben wir SPRITE_DRAW den Sprite, der gezeichnet werden soll. Hierbei benutzen wir den Eintrag des Datenfeldes Spr() mit dem Index FIX(RND*20), was eine Zufallszahl zwischen 0 und 20 ist. Dadurch werden zufällige Sprites ausgegeben.

Dieser Datentyp hat nur zwei Elemente: T gibt den Typ an, und E gibt an, wie viele Gegenstände dieses Typs im Inventar sind bzw. wie lange der Gegenstand noch aktiv ist usw.

Jetzt erstellen wir den Datentyp ObjType:

Wie Sie sehen, habe ich "eigenmächtig" noch die Elemente OX und OY eingeführt. Diese Variablen enthalten Sicherungswerte. Wir werden sie noch benötigen, wenn wir uns mit der Steuerung auseinandersetzen.

Auch für diesen Datentyp brauchen wir einige globale Variablen als Hilfe:

ObjDummy ist ein leeres Objekt und MAX_DIFF gibt an, wie genau Kollisionen geprüft werden sollen. Nachdem wir den globalen Teil des Moduls erstellt haben, kommen jetzt die OBJ_xxxxxxx Routinen. Auf ihnen basiert das ganze Spiel.

Fangen wir mit OBJ_SET an, da man mit dieser Routine neue Objekte erstellen kann.

Der Routine wird einmal das zu setzende Objekt (O As ObjectType) übergeben und die Werte, die für die Einstellungen relevant sind. Nach den Koordinaten, der Energie und der Geschwindigkeit in X- und Y-Richtung wird der Typ des Objekts übergeben. Danach kommt noch der Sprite, der für das Objekt gezeichnet werden soll und die Unsichtbar-Eigenschaft des Objekts.

Parallel dazu die Routine OBJ_CLEAR, die ein bestehendes Objekts löscht, indem es alle Eigenschaften des Objekts auf Null setzt:

In dieser Routine werden erst die "normalen" Eigenschaften des übergebenen Objekts O auf Null gesetzt und anschließend wird auch noch das Inventar geleert.

Mit diesen beiden Prozeduren können wir nun Objekte anlegen und wieder löschen. Uns fehlen jetzt noch Routinen zum Anzeigen, zur Kollisionsprüfung und zur Verwaltung des Inventars. Und wenn wir die fertig haben? Wie sollen wir dann das Spiel programmieren? Es gibt zwei Möglichkeiten:

Die Wahl die ich für Sie getroffen habe ist klar: Wir arbeiten entsprechend Punkt 2, da wir die andere Möglichkeit ja schon kennen und wissen, dass sie nicht sehr flexibel ist.

Um diese abgewandelte Form der richtigen objektorientierten Programmierung (OOP) zu verwirklichen benötigen wir einige globale Konstanten. Eine Konstante ist nichts anderes als eine Variable deren Wert nicht geändert werden kann. Um eine globale Konstante zu definieren benutzten wir den Befehl:

Diese Anweisung funktioniert nur im Deklarationenteil eines Moduls. Also öffnen Sie im Modul OBJECT.BAS die Prozedur "(allgemein) / (Deklarationen)". Jetzt müssen wir uns überlege welche Konstanten wir benötigen.

Um einfach Ereignisse verarbeiten zu können, bekommt jedes mögliche Ereignis eine feste (konstante) Nummer. Wir brauchen dann nur noch die übergebene Variable, die den Ereigniswert beinhaltet, mit einer Konstante vergleichen und können so entsprechend darauf reagieren. Und warum nehmen wir dafür nicht einfach Zahlen wie etwa "If Ereignis = 1 Then..."? Ganz einfach weil man sich Wörter leichter merken kann als Zahlen und man später den Sinn der Abfrage besser nachvollziehen kann, wenn dort steht "If Ereignis = ID_DRAW Then...".

Nun zu den Konstanten, die wir für das Spiel benötigen:

Diese Ereignisse werden natürlich nicht ohne unser Zutun ausgelöst. Die Routine OBJ_DRAW, die wir gleich kennen lernen, löst beispielsweise vor dem Zeichnen das Ereignis ID_DRAW aus, damit das Objekt vorher noch den zu zeichnenden Sprite setzen kann.

Jetzt kommt die einfache aber sehr elementare Routine OBJ_DRAW, die ein Objekt überhaupt erst auf den Bildschirm bringt:

Der Routine OBJ_DRAW wird außer dem zu zeichnenden Objekt noch ein Koordinatenpaar übergeben, das genauso wie beim Spielfeld aus Offset zur eigenen Position zu verstehen ist. Das bedeutet, der Sprite wird relativ zu seiner Position um X Einheiten nach rechts und um Y Einheiten nach unten verschoben. Dadurch können wir, wenn wir das Offset für das Spielfeld haben, es ebenfalls an die Routine OBJ_DRAW übergeben. Als letzter Parameter wird noch das Ausgabebildfeld übergeben.

In der Routine selbst wird zuerst geprüft, ob das Objekt überhaupt belegt ist. Bekanntlich gibt das Element T ja an, welcher Objekttyp vorliegt. Ist dieser Typ=0 geht die Routine davon aus, dass das Objekt nicht benutzt wird und lässt den Sprite aus. In der nächsten Zeile wird das Ereignis ID_DRAW ausgelöst. Dazu wird die Routine OBJ_EVENT (die wir gleich besprechen werden) ausgelöst. Diese verlangt folgende Parameter:

Das Objekt ist in diesem Fall natürlich O, das Ereignis ist ID_DRAW. Der Auslöser ist ein Objekt, das für das Auslösen des Ereignisses verantwortlich ist. In unserem Fall übergeben wir hier ObjDummy, da kein Auslöser vorhanden ist. Für die Zusatzwerte übergeben wir 0. Diese dienen nur für bestimmte Ereignisse, die weitere Parameter erfordern.

Im Anschluss daran werden die Koordinaten berechnet und der Sprite des Objekts (O.FRAME) wird mit Hilfe der Prozedur SPRITE_DRAW ausgegeben.
Nun zur Routine OBJ_EVENT, die, ob Sie es glauben oder nicht sehr kurz ausfällt:

“press i to see see the inventory” Solche Sätze kennt vielleicht der eine oder andere unter ihnen noch aus den guten alten Adventure-Spielen. Nun, in diesem Spiel werden wir auch ein Inventar verwenden. Jedoch beschränken wir uns dabei nicht auf “Aufnehmen” und “Ablegen” sonder wir schreiben flexible Routinen zum Verwalten des Inventars. Das klingt vielleicht etwas schwierig, aber es ist eine recht einfache Aufgabe:

Die Prozedur OBJ_ITEM_GET sorgt dafür, dass ein neuer Gegenstand dem Inventar hinzugefügt wird. Am Anfang kommt die obligatorische Abfrage der Objektbelegung. In den nächsten Prozedur-Beschreibungen werde ich diesen Teil weglassen. Nun werden alle Einträge des Inventars durchlaufen und es wird überprüft, ob noch ein freier Platz da ist. In diesem Fall wird dieser mit der übergebenen Objektnummer und der "Energy" belegt. Anschließend wird die Routine beendet.

OBJ_ITEM_DROP ist die genaue Umkehrung: Es durchsucht das Inventar und wirft den Gegenstand, falls vorhanden, heraus.

OBJ_ITEM_HAVE gibt den Energy-Wert des Gegenstandes zurück. Damit kann man nicht nur prüfen, ob der Gegenstand im Inventar vorhanden ist, sondern man kann damit gleichzeitig feststellen, wie viele Gegenstände es sind bzw. wie lange das Extra noch wirkt o.ä.. Der Aufbau dieser Funktion sollte auch nicht schwer zu verstehen sein, da er parallel zu den bisherigen ist.

Was soll denn das? Warum schreiben wir eine Funktion, die das genau das Gleiche macht, wie eine andere? Tja, das hat etwas mit Einheitlichkeit zu tun ;-)

Die Funktion OBJ_ITEM_ENERGY_GET soll das Gegenstück zu OBJ_ITEM_ENERGY_SET sein. Dass die Funktion OBJ_ITEM_HAVE auch die Energie zurückgibt, ist eigentlich nur eine Spielerei.

Die Routine OBJ_ITEM_ENERGY_SET sucht den übergebenen Gegenstand und setzt seine Energie neu. Ist der Gegenstand noch nicht im Inventar vorhanden, so wird er aufgenommen.

Noch etwas: Alle Inventar-Routinen arbeiten mit Gegenstandsnummern. Sie unterscheiden also nach Gegenstand Typ 1, Typ 2 usw.. Daher werden wir für diese Funktionen später auch mit "Global Const" Konstanten festlegen, die jedem möglichen Gegenstand eine Nummer zuweisen.

Wie oben schon erwähnt hat die Energie im Zusammenhang mit Gegenständen nicht unbedingt wirklich etwas mit Energie zu tun, sondern kann auch angeben, wie lange ein bestimmtes Extra noch hält, oder es steht für eine andere numerische Eigenschaft des Gegenstandes.

Noch eine letzte OBJ-Routine, die nichts mit dem Inventar zu tun hat, bevor wir mit dem Hauptprogramm anfangen:

Diese Routine bekommt vier Werte übergeben. C1 und C2 sind zwei Zählervariablen und Max1 bzw. Max2 sind die entsprechenden Maximalwerte. Jedes Mal wenn man diese Routine mit den gleichen Variablen aufruft wird C1 um 1 erhöht. Ist C1 größer als der Maximalwert für C1, so wird C1 auf 0 gesetzt und C2 wird um 1 erhöht. Ist C2 größer als der entsprechende Maximalwert wird auch C2 wieder auf 0 gesetzt. Ein Beispiel dazu:

Diese Routine dient zur Animation. Aber dazu im nächsten Teil mehr.

Wie Ende? Warum denn? Das kann ich Ihnen wohl sagen: Wenn ich den Kurs jetzt noch weiter ausdehne fürchte ich, dass ich selbst die Übersicht verliere und nur noch unvollständige und unverständliche Sätze schreibe ;-)

In Teil 4 wird das Hauptprogramm besprochen. Ihm steht auch ein eigener Kursteil zu, da es alleine (vom Speicherbedarf her) so groß ist, wie die bisher besprochenen Module zusammen.

Wenn Sie weitere Themenwünsche oder Ideen für den nächsten Aufbaukurs haben, schreiben Sie mir doch einfach eine eMail. Meine Adresse:

 go12power@hotmail.com

Wie immer freue ich mich auch über jede Art von Feedback zu dem Kurs und über Fragen zu VB oder anderen Themen. Wenn Sie Zeit haben, können Sie ja die Programmierer-Konferenz besuchen, die immer Donnerstags um 20:00 Uhr im Konferenzraum 2 von AOL stattfindet (STRG+K Konferenzen, Raum 2).

Ich hoffe, wir sehen uns dann wieder.