Gaming Tips by Andrew Barber (Chronic) and Andy Nicholas
übersetzt von Windapple mit der Genehmigung von Andi Nicholas
Dieser Abschnitt enthält verschiedene Hinweise und Tipps der Experten um dir eine bessere Struktur in deinen Spielen nahezubringen. Hier versuchen wir die Fehler und Stolpersteine ausfindig zu machen, über die viele Programmierer fallen und dir dabei zu helfen, ein professioneller aussehendes Spiel zu erstellen.
Saubere Spiele
Wenn du ein Spiel machst weißt du was du tust, du weißt welche Sprites was darstellen, welche Objekte was tun, wozu deine Skripte da sind und was dein Code so treibt. Aber komme mal nach ein paar Monaten zurück und versuche dich zu erinnern, was was war!
Es passiert, und sich durch das Spiel zu wühlen um zu sehen wo Sprite8 verwendet wird oder was Object12 tut macht am Ende nur Kopfschmerzen. Dieses Tutorial versucht dieses Problem zu beseitigen und dir zu helfen eine "sauberere Spielstruktur" zu haben. Auch gehen wir hier auf Geschwindigkeitszusammenhänge ein, also wie man ein Spiel schneller machen kann.
Benennung
Eines der meisten Dinge, die ich sah, ist, das die User einfach ihre Sprites nicht benennen, sie lassen die einfach so wie sie erstellt wurden, [Sprite0, Sprite1, etc]. Nunja, da spricht nix dagegen, aber ihm einen aussagekräftigeren Namen geben hilft später beim programmieren und bei der zuordnung des Sprites, Beispielsweise..
spr_player_left
Zuerst das "spr_", das ist dazu da um ein Sprite eindeutig als solches zu bezeichnen. Das "spr_" ist nur dazu da das Sprite eindeutig zu machen damit Game Maker nicht bei der Wahl des zu Zeichnenden durcheinander kommt.
Der nächste Teil, "player_", bezeichnet die Verwendung des Sprites, in diesem Fall als Sprite für den Spieler.
Und schließlich "left", das sind zusätzliche 'Notizen' für das Sprite. Darum sagt mir spr_player_left das dies das Sprite des nach links gehenden Spielers ist. Hier sind noch mehr Beispiele:
spr_player_right
spr_boss1_shooting_laser
spr_ghost_dead
Dasselbe kannst du auch bei Objekten machen, setze einfach ein obj_ davor, das beugt Verwechslungen zwischen Objekten und Sprites vor. Die Objekte für das vorherige Beispiel würden als so heißen:
obj_player_right
obj_boss1_shooting_laser
obj_ghost_dead
Sortieren
Ein anderer oft gesehener Fehler ist das fehlen von GRUPPEN, diese sind ungemein nützlich um die verschiedenen Spielelemente wie Sprites/Sounds/Objekte etc. zu "sortieren".
Werfen wir einen Blick auf folgende Abbildungen, einmal Objekte ohne Gruppen und einmal dasselbe mit Gruppen:
Wie du sehen kannst ist die zweite Methode sehr viel übersichtlicher, du weißt welche Sprites wo sind und kannst direkt dort hingehen. Um eine Gruppe zu erzeugen klickst du mit der linken Maustaste in die Explorer-ähnliche linke Leiste im Game Maker Fenster, z.B. auf SPRITES, im Kontextmenü wählst du dann ADD GROUP und gibst der Gruppe einen Namen, sowas wie Gegner, und nun ziehst du einfach alle Gegner in diese Gruppe. Wenn du bereits ein Sprite gemacht hast, das in der falschen Gruppe ist kannst du es einfach in die richtige ziehen. Das funktioniert mit allen Game Maker Elementen wie Objekte/Sounds/Räume etc.
Der Code
Beim Programmieren wirst du sehr bald die kleinen Kniffe lernen, die ein Spiel beschleunigen und die Dateigröße reduzieren.. nach allem ist es immer noch die Dateigröße, die Spieler wollen nicht über 1 Stunde an einem 56k Modem sitzen das sie 5 Cent Vernindungsgebühr pro Minute kostet.
Beispielsweise ist es absolut unsinnig dies zu tun..
wenn man es auch kürzer haben kann..
Wenn du ein langes Skript geschrieben hast und du es jetzt so im Spiel lässt, weil es gut genug ist, aber später etwas hinzufügst wozu du das besagte Skript editieren musst, bemerkst du aber beim zurückkehren das du keine Ahnung mehr hast wie der Cide eigentlich funktioniert. Es ist eine gute Idee KOMMENTARE in das Skript zu schreiben, sodass du dich später noch daran erinnern kannst. Indem du den Schrägstrich doppelz benutzt "//" teilst du dem Game Maker mit, das das folgende ein KOMMENTAR ist.
zum Beispiel
Es gibt auch ein Kommentar-Icon das im Code Tab gefunden werden kann.
Flexibles Programmieren
Wenn du nicht gerade ein Programmierer bist stehen die Chancen schlecht, das du jemals von dem Begriff "Hard coding" gehört hast, oder ihn gehört/gelesen hast aber nicht weißt, was er bedeutet!
Aber ist der hier relevant? Hat das irgendwas mit dem Game Maker zu tun?
Ja, es ist in jeder Programmiersprache relevant, ob in Basic oder GML, aber was ist nun Hard Coding?
Hard Coding ist wenn dein Code nicht flexibel ist wenn du Veränderungen vornimmst. Verwirrt? Ich zeige dir ein paar Beispiele:
Beispiel #1
Sagen wir du hast ein Spiel, in dem 10 Objekte auf der rechten Bildschirmseite erstellt werden, die Auflösung ist 640x480, die Objekte sind 32 x 32 Pixel groß und du erstellst die Objekte in der Form: instance_create(x,y,object1), instance_create(x,y,object2), instance_create(x,y,object3)...
Weil du sie natürlich rechts haben möchtest würde x 640 sein (die Bildschirmbreite), aber du musst auch das Sprite berücksichtigen (32 Pixel), also müssen wir die 32 von den 640 abziehen was 608 ergibt, also schreibst du hin:
Was passier nun aber, wenn du die Bildschirmbreite änderst? Oder die breite eines Sprites? Weil du x hard gecodet hast (oder einen absoluten Wert angegeben hast), musst du alle 10 Werte ändern, und was passiert wenn sich die Breite wieder ändert? Zurück in den Code...
Wie du sehen kannst kann schon die kleinste Veränderung an einer Stelle dich den Code des ganzen Spieles überprüfen und die Werte ändern lassen, deswegen ist Hard coding für einige Stellen nicht empfohlen, es wäre besser wenn man sowas hätte:
Damit wirst du unabhängig von der Bildschirmgröße oder der Sprite Breite nie den Code ändern müssen, da room_width - sprite_width automatisch die Position des Objektes berechnet!
Beispiel #2:
Du möchtest 3 Zeilen Text anzeigen, die erste soll bei 100 Pixeln von oben beginnen, und zwischen den Zeilen soll ein Abstand von je 10 Pixeln sein, so ist hier die erste Codezeile:
Du fängst bei 100 Pixeln von oben an.
Nun brauchen wir eine Lücke von je 10 Pixeln zwischen jeder Zeile, um also die Position der nächsten Zeile zu bekommen fügen wir 10 zur ersten Position hinzu (100), das macht 110, und wir müssen auch die Schriftgröße hinzufügen, damit sich das nicht überlappt; 110 + 20 = 130, also beginnt die nächste Zeile bei 130:
Nochmals fügen wir 10 für den Abstand und die größe der Schrift hinzu; 130 + 10 + 20 = 160 um die dritte Position anzugeben:
Dein Code sieht also letztendlich so aus:
Aber was ist, wenn du die Position aller Zeilen vielleicht ab 230 anstelle von 100 Pixeln beginnen willst? Oder wenn du den Zeilenabstand ändern möchtest? Sieht so aus als ob du alle Positionen neu berechnen musst, das ist Hard coding, absolute Wert eintragen, die Änderungen gegenüber nicht flexibel sind. Eine viel bessere und variablere Möglichkeit ist diese hier:
xpos+(gap+font_size)*number positioniert die Zeile jeweils immer korrekt. Es sieht zwar ziemlich umständlich aus, aber dies erlaubt flexibles Programmieren. Es ist egal wie viele Zeilen du hast, du musst immer nur 3 Variablen änden; font_size, xpos und gap!
Zeichnen
Wenn du irgendwas zeichnen möchtest, wie eine Gesundheitsanzeige oder Leben, MÜSSEN die Aktionen dafür im Draw Event eines Objektes durchgeführt werden, wenn du sie sonst irgendwo einfügst, beispielsweise im Create Event, werden sie nicht gezeichnet. Logisch wäre es, die Aktionen im Draw Event des Spielers / Characters unterzubringen, aber dann siehst du, das das Sprite des Spielers / Characters nicht mehr angezeigt wird, was geht da vor sich?
Sobald etwas sich im Draw Event befindet überschreibt dies das anzeigen des mit dem Objekt verbundenen Sprites, einfach gesagt "Ah, es ist etwas zum zeichnen vohanden, also ignoriere ich das angegebene Sprite.".
Es gibt eine Menge Wege drum herum, die erste und beste Methode ist ein 'leeres' Objekt ohne Sprite zu erstellen (meist Controller genannt) und du deine Zeichenaufgaben dort einfügst, stelle aber sicher das 'visible' angeschaltet ist und platziere den Controller irgendwo im Raum.
Die zweite Möglichkeit ist das Spieler / Character das Sprite im Draw Event zeichnen zu lassen. Das kann mit diesem Code erledigt werden:
draw_sprite(sprite,subimg,x,y)
Bzw.:
draw_sprite(sprite_player,-1,obj_player.x,obj_player.y)
Das -1 für subimage lässt das aktuelle subimage anzeigen.
Hiermit wird das Spieletipps Tutorial für jetzt beendet, in der Zukunft wird wohl noch mehr hinzugefügt werden und ich hoffe es ist dir eine Hilfe bein erstellen besserer, "saubererer" Spiele.
Dieser Inhalt ist unter einer Creative Commons-Lizenz lizenziert.
übersetzt von Windapple mit der Genehmigung von Andi Nicholas
Dieser Abschnitt enthält verschiedene Hinweise und Tipps der Experten um dir eine bessere Struktur in deinen Spielen nahezubringen. Hier versuchen wir die Fehler und Stolpersteine ausfindig zu machen, über die viele Programmierer fallen und dir dabei zu helfen, ein professioneller aussehendes Spiel zu erstellen.
Saubere Spiele
Wenn du ein Spiel machst weißt du was du tust, du weißt welche Sprites was darstellen, welche Objekte was tun, wozu deine Skripte da sind und was dein Code so treibt. Aber komme mal nach ein paar Monaten zurück und versuche dich zu erinnern, was was war!
Es passiert, und sich durch das Spiel zu wühlen um zu sehen wo Sprite8 verwendet wird oder was Object12 tut macht am Ende nur Kopfschmerzen. Dieses Tutorial versucht dieses Problem zu beseitigen und dir zu helfen eine "sauberere Spielstruktur" zu haben. Auch gehen wir hier auf Geschwindigkeitszusammenhänge ein, also wie man ein Spiel schneller machen kann.
Benennung
Eines der meisten Dinge, die ich sah, ist, das die User einfach ihre Sprites nicht benennen, sie lassen die einfach so wie sie erstellt wurden, [Sprite0, Sprite1, etc]. Nunja, da spricht nix dagegen, aber ihm einen aussagekräftigeren Namen geben hilft später beim programmieren und bei der zuordnung des Sprites, Beispielsweise..
spr_player_left
Zuerst das "spr_", das ist dazu da um ein Sprite eindeutig als solches zu bezeichnen. Das "spr_" ist nur dazu da das Sprite eindeutig zu machen damit Game Maker nicht bei der Wahl des zu Zeichnenden durcheinander kommt.
Der nächste Teil, "player_", bezeichnet die Verwendung des Sprites, in diesem Fall als Sprite für den Spieler.
Und schließlich "left", das sind zusätzliche 'Notizen' für das Sprite. Darum sagt mir spr_player_left das dies das Sprite des nach links gehenden Spielers ist. Hier sind noch mehr Beispiele:
spr_player_right
spr_boss1_shooting_laser
spr_ghost_dead
Dasselbe kannst du auch bei Objekten machen, setze einfach ein obj_ davor, das beugt Verwechslungen zwischen Objekten und Sprites vor. Die Objekte für das vorherige Beispiel würden als so heißen:
obj_player_right
obj_boss1_shooting_laser
obj_ghost_dead
Sortieren
Ein anderer oft gesehener Fehler ist das fehlen von GRUPPEN, diese sind ungemein nützlich um die verschiedenen Spielelemente wie Sprites/Sounds/Objekte etc. zu "sortieren".
Werfen wir einen Blick auf folgende Abbildungen, einmal Objekte ohne Gruppen und einmal dasselbe mit Gruppen:
Wie du sehen kannst ist die zweite Methode sehr viel übersichtlicher, du weißt welche Sprites wo sind und kannst direkt dort hingehen. Um eine Gruppe zu erzeugen klickst du mit der linken Maustaste in die Explorer-ähnliche linke Leiste im Game Maker Fenster, z.B. auf SPRITES, im Kontextmenü wählst du dann ADD GROUP und gibst der Gruppe einen Namen, sowas wie Gegner, und nun ziehst du einfach alle Gegner in diese Gruppe. Wenn du bereits ein Sprite gemacht hast, das in der falschen Gruppe ist kannst du es einfach in die richtige ziehen. Das funktioniert mit allen Game Maker Elementen wie Objekte/Sounds/Räume etc.
Der Code
Beim Programmieren wirst du sehr bald die kleinen Kniffe lernen, die ein Spiel beschleunigen und die Dateigröße reduzieren.. nach allem ist es immer noch die Dateigröße, die Spieler wollen nicht über 1 Stunde an einem 56k Modem sitzen das sie 5 Cent Vernindungsgebühr pro Minute kostet.
Beispielsweise ist es absolut unsinnig dies zu tun..
wenn man es auch kürzer haben kann..
Wenn du ein langes Skript geschrieben hast und du es jetzt so im Spiel lässt, weil es gut genug ist, aber später etwas hinzufügst wozu du das besagte Skript editieren musst, bemerkst du aber beim zurückkehren das du keine Ahnung mehr hast wie der Cide eigentlich funktioniert. Es ist eine gute Idee KOMMENTARE in das Skript zu schreiben, sodass du dich später noch daran erinnern kannst. Indem du den Schrägstrich doppelz benutzt "//" teilst du dem Game Maker mit, das das folgende ein KOMMENTAR ist.
zum Beispiel
Es gibt auch ein Kommentar-Icon das im Code Tab gefunden werden kann.
Flexibles Programmieren
Wenn du nicht gerade ein Programmierer bist stehen die Chancen schlecht, das du jemals von dem Begriff "Hard coding" gehört hast, oder ihn gehört/gelesen hast aber nicht weißt, was er bedeutet!
Aber ist der hier relevant? Hat das irgendwas mit dem Game Maker zu tun?
Ja, es ist in jeder Programmiersprache relevant, ob in Basic oder GML, aber was ist nun Hard Coding?
Hard Coding ist wenn dein Code nicht flexibel ist wenn du Veränderungen vornimmst. Verwirrt? Ich zeige dir ein paar Beispiele:
Beispiel #1
Sagen wir du hast ein Spiel, in dem 10 Objekte auf der rechten Bildschirmseite erstellt werden, die Auflösung ist 640x480, die Objekte sind 32 x 32 Pixel groß und du erstellst die Objekte in der Form: instance_create(x,y,object1), instance_create(x,y,object2), instance_create(x,y,object3)...
Weil du sie natürlich rechts haben möchtest würde x 640 sein (die Bildschirmbreite), aber du musst auch das Sprite berücksichtigen (32 Pixel), also müssen wir die 32 von den 640 abziehen was 608 ergibt, also schreibst du hin:
Was passier nun aber, wenn du die Bildschirmbreite änderst? Oder die breite eines Sprites? Weil du x hard gecodet hast (oder einen absoluten Wert angegeben hast), musst du alle 10 Werte ändern, und was passiert wenn sich die Breite wieder ändert? Zurück in den Code...
Wie du sehen kannst kann schon die kleinste Veränderung an einer Stelle dich den Code des ganzen Spieles überprüfen und die Werte ändern lassen, deswegen ist Hard coding für einige Stellen nicht empfohlen, es wäre besser wenn man sowas hätte:
Damit wirst du unabhängig von der Bildschirmgröße oder der Sprite Breite nie den Code ändern müssen, da room_width - sprite_width automatisch die Position des Objektes berechnet!
Beispiel #2:
Du möchtest 3 Zeilen Text anzeigen, die erste soll bei 100 Pixeln von oben beginnen, und zwischen den Zeilen soll ein Abstand von je 10 Pixeln sein, so ist hier die erste Codezeile:
Du fängst bei 100 Pixeln von oben an.
Nun brauchen wir eine Lücke von je 10 Pixeln zwischen jeder Zeile, um also die Position der nächsten Zeile zu bekommen fügen wir 10 zur ersten Position hinzu (100), das macht 110, und wir müssen auch die Schriftgröße hinzufügen, damit sich das nicht überlappt; 110 + 20 = 130, also beginnt die nächste Zeile bei 130:
Nochmals fügen wir 10 für den Abstand und die größe der Schrift hinzu; 130 + 10 + 20 = 160 um die dritte Position anzugeben:
Dein Code sieht also letztendlich so aus:
Aber was ist, wenn du die Position aller Zeilen vielleicht ab 230 anstelle von 100 Pixeln beginnen willst? Oder wenn du den Zeilenabstand ändern möchtest? Sieht so aus als ob du alle Positionen neu berechnen musst, das ist Hard coding, absolute Wert eintragen, die Änderungen gegenüber nicht flexibel sind. Eine viel bessere und variablere Möglichkeit ist diese hier:
GML-Quellcode
- xpos = 100; // The x position of the first line
- gap = 10; // The size of the gap between lines
- font_size = 20;
- draw_text(0,xpos,"First line of text")
- draw_text(0,xpos+gap+font_size,"Second line of text")
- draw_text(0,xpos+(gap+font_size)*2,"Third line of text")
- draw_text(0,xpos+(gap+font_size)*3,"Forth line of text")
- ...
xpos+(gap+font_size)*number positioniert die Zeile jeweils immer korrekt. Es sieht zwar ziemlich umständlich aus, aber dies erlaubt flexibles Programmieren. Es ist egal wie viele Zeilen du hast, du musst immer nur 3 Variablen änden; font_size, xpos und gap!
Zeichnen
Wenn du irgendwas zeichnen möchtest, wie eine Gesundheitsanzeige oder Leben, MÜSSEN die Aktionen dafür im Draw Event eines Objektes durchgeführt werden, wenn du sie sonst irgendwo einfügst, beispielsweise im Create Event, werden sie nicht gezeichnet. Logisch wäre es, die Aktionen im Draw Event des Spielers / Characters unterzubringen, aber dann siehst du, das das Sprite des Spielers / Characters nicht mehr angezeigt wird, was geht da vor sich?
Sobald etwas sich im Draw Event befindet überschreibt dies das anzeigen des mit dem Objekt verbundenen Sprites, einfach gesagt "Ah, es ist etwas zum zeichnen vohanden, also ignoriere ich das angegebene Sprite.".
Es gibt eine Menge Wege drum herum, die erste und beste Methode ist ein 'leeres' Objekt ohne Sprite zu erstellen (meist Controller genannt) und du deine Zeichenaufgaben dort einfügst, stelle aber sicher das 'visible' angeschaltet ist und platziere den Controller irgendwo im Raum.
Die zweite Möglichkeit ist das Spieler / Character das Sprite im Draw Event zeichnen zu lassen. Das kann mit diesem Code erledigt werden:
draw_sprite(sprite,subimg,x,y)
Bzw.:
draw_sprite(sprite_player,-1,obj_player.x,obj_player.y)
Das -1 für subimage lässt das aktuelle subimage anzeigen.
Hiermit wird das Spieletipps Tutorial für jetzt beendet, in der Zukunft wird wohl noch mehr hinzugefügt werden und ich hoffe es ist dir eine Hilfe bein erstellen besserer, "saubererer" Spiele.
Dieser Inhalt ist unter einer Creative Commons-Lizenz lizenziert.
"Die Erde ist ein Irrenhaus. Dabei könnte das bis heute erreichte Wissen der Menschheit aus ihr ein Paradies machen. Dafür müsste die weltweite Gesellschaft allerdings zur Vernunft kommen."
- Joseph Weizenbaum
- Joseph Weizenbaum
