@real Troll
Der wesentlichste Unterschied ist wohl, dass der Game Maker nicht spezialisiert ist. Das ist Fluch und Segen zugleich. Auf der einen Seite bietet das Werkzeug viel mehr Möglichkeiten, auf der anderen Seite erfordert es auch mehr Einarbeitung, es sei denn in der neusten Version gibt es jetzt schon Presets für Rollenspiele.
Ich hab dein Tutorial jetzt durch.
Als erste Lektion ist es wirklich sehr gut geeignet und man kommt zu einem schönen Ergebnis. Der Aufbau ist auch erste Sahne. Allerdings sehe ich da zwei gravierende Problemzonen.
1) Es gibt sehr vieles, das du nicht ausreichend bis gar nicht erklärst. Du erläuterst, wie du vorgehst und man kann es problemlos nachbauen, aber an einigen Stellen bleibt u.a. das Verständnis für das, was man da eigentlich tut, auf der Strecke.
Warum z.B. haben wir die Farbe unter den defaultsettings eingestellt? (Genaugenommen nutzen wir diese gar nicht bzw. nicht als solche.) Du erwähnst ja noch den Fall einer möglichen gelben default color. Stattdessen stellen wir die weisse Farbe (im späteren Verlauf) jedes mal auf's Neue manuell ein. An dieser Stelle müsste es so wie bei der Farbe des Schattens geschrieben werden.
Beispielsweise:
c_default = c_white;
Es wäre auch sinnvoll, zu erwähnen, warum man einmal c_white schreibt und ein anderes mal eine Farbe über make_color_rgb festlegt.
2) Für den Anfang sind es zuviele Informationen. Bei dem Teil mit dem Schatten hast du mich komplett verloren.
Die Sache mit dem Skript ist viel zu kompliziert für den Einstieg. Du hast gut erklärt, was in dem Script selbst passiert, aber nicht, wie man dieses verwendet oder wie ein Script an sich funktioniert. Argumente oder die vertauschte Reihenfolge von Argument 3 und 4 (ich kann mir denken warum, aber das wird nicht auf jeden zutreffen) sind hier nicht nachvollziehbar.
Sinnvoller wäre an der Stelle gewesen, es erstmal einfacher, wenn auch weniger elegant zu lösen. Den Text beispielsweise simpel zweimal mit dem gleichen Code-Block zeichnen und nur die Werte usw. anpassen. Hier kann man dann auch gut erwähnen, dass wir das zu einem späteren Zeitpunkt nochmal aufgreifen um es eben eleganter, für ein besseres Verständnis aber erstmal so lösen.
Ich gehe mal davon aus, dass du Scripts bereits eingeführt hast, da wir diese in der nächsten Lektion wieder nutzen werden. Trotzdem finde ich, dass man dies ans Ende der Titelmenüreihe setzen sollte. Viel wichtiger, als es auf Anhieb möglichst ordentlich zu machen, ist, zu verstehen was man tut. Optimierungen sollten zugunsten eines leichteren Einstiegs auf einen späteren Zeitpunkt verlegt werden. Das Tempo ist für die erste Lektion einfach deutlich zu hoch.
Wenn du es unbedingt bereits einführen willst, dann muss es ausreichend erklärt werden. Dein Beispiel eignet sich durchaus gut, um dies in wenigen Worten zu erreichen. Sofern man es nicht doch irgendwie begriffen haben sollte, müsste man sich momentan anderweitig in einem solchen Umfang in das Thema einlesen, dass es den Rahmen des Tutorials sprengen würde. Wenn man es erstmal verstanden hat, ist so ein Script nurnoch eine Kleinigkeit, aber bevor es soweit ist, kann man sich daran die Zähne ausbeissen.
Eine andere Möglichkeit wäre, einmal klar und deutlich zu sagen, dass wir einiges im Rahmen dieser Lektion, um den Lernenden nicht zu überfordern, unkommentiert lassen, mit dem Hinweis, später (gut und gerne auch in einer anderen Lektion) im Einzelnen darauf einzugehen. Dies sollte dann aber auch möglichst bald geschehen, damit der rote Faden nicht verloren geht.
Da es sich um einen Einstiegskurs handelt, muss man es aus der entsprechenden Perspektive betrachten. Du hast bereits ausreichend Erfahrung und weisst natürlich, was du tust. Ebenso werden Leute mit Programmiererfahrung sicher schnell dahintersteigen. Die Wahrscheinlichkeit, dass sich ein Anfänger nicht zurechtfindet, ist aber enorm groß.
Der Sinn eines Tutorials sollte es nicht sein, dem Lernenden zu zeigen, wie man es nachbaut, sondern ihm beizubringen, es hinterher selber bauen zu können. Momentan geht es leider, wenn man es ganz hart ausdrückt, eher in Richtung Malen-nach-Zahlen.
Kelven hat es eigentlich schon ganz gut zusammengefasst. Du kannst jeden Aspekt deines RPGs so gestalten wie du möchtest, vom Menü hin zum Kampfsystem. Diese gestalterische Freiheit kommt aber auch daher, dass du jeden Aspekt selber skripten musst. Das hört sich schwerer an als es ist, da der GMS2 eine Vielzahl an Funktionen in der Rückhand hat, die man einfach implementieren kann (z.B. Collision, etc.).Zitat von real Troll
Freut mich!Großartige Sache!
Da ich mir vor geraumer Zeit Game Maker Studio gekauft hatte, mich in naher Zukunft mehr damit auseinandersetzen wollte und dann ohnehin nach Tutorials für den Einstieg gesucht hätte, kommt diese Tutorialreihe hier wie gerufen. Alles schön Schritt für Schritt, in leicht verdaulichen Happen und großzügig bebildert... Ich bin schon mal gespannt auf die kommenden Lektionen.Einen Großteil der Codefragmente wirst du auch im GMS1 nutzen können, das Tutorial ist aber für den GMS2 ausgelegt.
@Nagasaki:
Danke für dein Feedback und das es dir gefallen hat! So ein Feedback ist mir wichtig, damit ich weiß, an welchen Stellen ich zu schnell war und wo nochmal Nachholbedarf herrscht. Ich werde die Hinweise nochmal einpflegen, um es aber schonmal kurz anzuskizzieren:
a) die draw_text(x, y, string)-Funktion hat keine Farbauswahl, deswegen schreibe ich aus Prinzip vor jedem Drawevent die Defaultfarbe und den Defaultfont hin für Funktionen, die beide nicht vorher einstellen. Werde ich an dieser Stelle besser erklären.
b) c_white ist eine Standardfarbe, die im GMS schon vorgegeben ist. Das Grau für den Schatten ist nicht vorhanden, deswegen muss es über make_color_rgb(); festgelegt werden. Dieser Sprung war zu weit, ich werde das im Text schöner beschreiben, damit jeder besser mitkommt.
Nun zu deinem zweiten Punkt, ich werde kurz meine Designphilosophie und die damit verbundenen Baustellen erklären:
Lektion 1 nimmt eine Sonderstellung in diesem Tutorial ein. Mein Ziel war es, dass am Ende der Lektion ein schönes Endergebnis vorliegt und der User sagen kann: "Ja, ich hab was erschaffen!". Ich finde, so etwas motiviert mehr als ein Tutorial, wo nach 4-5 Lektionen erst die ersten Ergebnisse angeschaut werden können. Für dieses Endergebnis habe ich eine etwas längere Lektion in Kauf genommen. bei denen manche Funktionen nur grob angerissen werden. Manches zu grob, deswegen werde ich ein paar Punkte nach deinen Vorschlägen überarbeiten.
Der User wird also einmal grob über paar Funktionen geführt und kriegt ein Gefühl für das IDE und wie man Sprites importiert und etwas codet. Er hat nun ein schönes und sichtbares Fundament, auf dem ich in den nächsten Lektionen sehr kleinschrittig aufbauen und wert darauf legen kann, dass er jeden Schritt genau nachvollzieht. Aus der groben Übersicht wird nun DetailwissenLektion 2 wird z.B. ein beweglicher Cursor sein, etwas was deutlich weniger Code ist und das Thema Skripte und Objekte nochmal aufgreift und erklärt. Das schöne dabei: Nach Lektion 2 haben wir ebenfalls ein schön sichtbares Endergebnis: Ein Cursor, den man hoch und runter bewegen kann!
Ich hoffe, dass erklärt den Aufbau von Lektion 1 und warum er eine Sonderstellung in diesem Tutorial einnimmt! Keine Angst, mit diesem Tempo wird es definitiv nicht weitergehen
Danke für die Erklärungen. Ja, der Skriptaspekt klingt erst mal abschreckend (und sieht auf den Beispielbildern auch abschreckend aus). Ich glaube, ich locke mein beinahe verschrecktes Interesse mit ein paar schönen Videos werbender Anwendungsbeispiele aus seinem Unterschlupf hervor. Die Suche nach "Game Maker RPG" spuckt eine durchaus ansehnliche Trefferzahl aus.
Gibt es denn besonders empfehlenswerte* Projekte?
*Sei es, weil sie staunen lassen, sei es, weil sie eine spezifische Game-Maker-Möglichkeit besonders gut illustrieren.
Sind einige international ausgezeichnete Spiele, die auf dem Gamemaker entstanden sind. Game-Maker-spezifische Möglichkeiten sind schwer zu nennen. Es ist eben eine deutlich allgemeinere Engine. Wenn es 2D ist, kannst du es damit umsetzen (<- das ist die spezielle Möglichkeit, die Gamemaker bietet).
Das beinhaltet auch Sachen wie vernünftigen Gamepad Support, Netcode, Shader...
Hier noch ein Showreel von 2016:
Geändert von WeTa (27.11.2016 um 18:29 Uhr)
Lektion 2: Cursor-Bewegung!
In der letzten Lektion haben wir unseren ersten Titelbildschirm gebastelt. Heute werde wir lernen, wie wir unseren Cursor mittels Tastendruck bewegen können! Damit nähern wir uns einen weiteren Schritt hin zum funktionierenden Menü! Diese Lektion umfasst:
- Was sind Variablen?
- Mehr Wissen über Skripte
- Funktion von Alarms in GMS2
Fangen wir nochmal bei Skripten an. Was genau ist ein Skript? Skripte sind Codezeilen, die immer wieder Verwendung während unseres Projekts finden. Da wir nicht jedesmal die gleichen Codezeilen eintippen wollen und unseren Code übersichtlich halten möchten, lohnen sich Skripte sehr! Skripte können unterschiedlich genutzt werden. Eine Möglichkeit ist die Codeauslagerung. Diese Methode werden wir gleich beim Input-Skript nutzen. Hierbei wird ein Codefragment, der immer wieder Anwendung findet, in ein Skript ausgelagert und kann über skript(); aufgerufen wurden. Der GM2 wird an der Stelle der Aufrufung dieses Codefragment reinkopieren.
Eine andere Möglichkeit ist es, ein Skript zu schreiben, dem wir Argumente zuschicken. So können wir z.B. ein Skript namens addition(argument0, argument1); schreiben. Wir übermitteln dem Skript dann zwei Zahlen und kriegen dann vom Skript den addierten Zahlenwert zurückgeschickt. Der GM2 hat solche Skripte selber schon eingebaut als Funktionen, wie z.B. die keyboard_check();-Funktion.
Das Additionsskript würde wie folgt aussehen:
Die dem Skript zugeschickten Argumente argument0 und argument1 werden in Variable a und b gespeichert, danach werde beide addiert und der neu errechnete Wert wird in Variable c gespeichert. Variable c wird dann vom Skript wieder zu dem Code zurückgeschickt, der das Skript aufgerufen hat.
Lasst uns dies an einem praktischem Beispiel vertiefen und verinnerlichen! Über Rechtsklick auf Scripts im Ressourcenfenster öffnen wir ein neues Skript und schreiben folgendes rein:
Der GM2 hat als Funktion keyboard_check(argument0);, das ist quasi ein Skript, dem wir als Argument eine Taste vorgeben, und die Funktion gibt uns aus, ob sie gedrückt ist (true) oder nicht gedrückt ist (false). Warum argument0? Der GM2 fängt beim Zählen immer bei 0 an. Wenn wir also diese Funktion aufrufen, kriegen wir ein "ja, gedrückt" oder "nein, nicht gedrückt" zurück. Diese Information speichern wir in eine Variable. Eine Variable im GMS2 kann unterschiedliche Datentypen speichern, sei es nun Zahl, String oder Boolean (true/false, 0/1). Die Variable muss beim GMS2 nicht vorher einem Typen zugeordnet werden. Das ganze sieht dann so aus:
right_key = keyboard_check(vk_right) or keyboard_check(ord("D"));
Übersetzt heißt es in dem Fall: Wenn die rechte Pfeiltaste (vk_right) gedrückt wurde, wird in der Variable right_key der Wert true abgespeichert, ansonsten false. Dieses Spiel machen wir auch für die anderen 3 Pfeiltastenrichtungen und wir haben sehr nützliche Codezeilen, die wir immer wieder aufrufen können über scr_input();, wenn wir die Tastenaufrufe in Variablen gespeichert haben möchten.
---
Gehen wir nun zu unserem bisher einzigen Objekt über, obj_titlemenu. Doppelklickt auf ihn. Wir fügen ein paar Codezeilen hinzu! Als erstes fügen für über Add Event ein neues Event hinzu, ein Create-Event. Code im Create-Event werden nur einmal aufgerufen, und zwar wenn das Objekt im Spiel erschaffen wird. Sonst nicht mehr! Schreibt folgendes rein:
Wir haben zwei Variablen initiiert, also dem Objekt gesagt, dass es sie gibt und er sie sich merken soll, cursor und max_cursor. Unser Titelmenü hat drei Unterpunkte, "Start", "Load" und "End", diese entsprechen den Zahlenwerten 0, 1, 2. Nicht vergessen, wir fangen bei 0 an zu zählen! In der variable cursor speichern wir ab, bei welchem Unterpunkt wir uns befinden, bei 0 also bei "Start". Als weitere Variable initiieren wir max_cursor. Diese Variable speichert den Wert ab, die den maximalen Unterpunkt im Menü widerspiegelt, also 2 und damit "End"! Warum das wichtig ist, erfahren wir gleich.
Als nächstes fügen wir ein Step-Event hinzu. Der Code im Step-Event wird jeden Frame abgerufen, immer und immer wieder. Hier schreiben wir rein, wie sich cursor verändert, wenn wir eine Taste drücken. Folgender Code kommt rein:
Was haben wir getan? Zuerst haben wir scr_input(); aufgerufen. Damit steht uns für den weiteren Code die Variablen up_key und down_key zur Verfügung, da sie in dem von uns geschriebenen Skript initiiert werden. Sehr praktisch und nur eine Zeile Code!
Anschließend folgt ein if-Statement. Der Aufbau ist z.B. if(argument0 == true) {führe diesen Code aus}.
Wir überprüfen also, ob die Bedingung für argument0 (in dem Fall: argument0 ist true) erfüllt ist und führen dann den Code aus, ansonsten bleibt dieser unangetastet! Das ist sehr praktisch, da wir so Code selektieren können! Die Bedingungen können ganz unterschiedlich sein, von argument > 10 (argument0 ist größer als 10) bis hin zu argument0 = "Peter" (wenn das Argument Peter beinhaltet, wird der Code ausgeführt). In meinem Fall steht if(down_key), das ist eine Kurzschreibweise. down_key ist entweder true/1 oder false/0. Wenn in der if-Abfrage nur der Variablenname steht, wird automatisch geprüft, ob die Variable true/1 ist und dann wird der Code ausgeführt.
In unserem Fall steht also if (down_key){cursor++}. Wenn die Taste nach unten gedrückt wird, dann wird der Code in der geschwungenen Klammer ausgeführt, in dem Fall also cursor++, das bedeutet, die Variable cursor wird um 1 erhöht.
Ich hoffe, diese Erklärung war verständlich genug, sonst fragt nochmal nach!
Wir überprüfen also, ob down_key gedrückt wurde. Wenn ja, wird der cursor um 1 erhöht (cursor++;). Das Problem hierbei ist, dass wir die Werte so über einen Maximalwert von 2 erhöhen können, bis wir mit dem Cursor aus dem Bildschirm rausfliegen! Aus diesem Grund bauen wir ein weiteres if-Statement ein, welches den Cursor wieder auf 0 setzt, wenn die cursor-variable über den Wert von max_cursor und damit 2 ist.
Das gleiche Prinzip gilt für den up_key. Kleine Transferübung: schaut euch den Code an und versucht ihn selber nachzuvollziehen! Wenn ihr euch sicher seid, lest weiter. Wenn nicht, lasst einen Kommentar da
Als nächstes Modifizieren wir das Draw-Event aus der vorherigen Lektion. Wir ändern den y-Wert beim spr_cursor! Zuvor stand da ein Wert von 145, bezogen auf die Camera. Nun modifizieren wir es zu 145 + 18*cursor.
Warum? Die Unterpunkte auf dem Bildschirm sind 18 Pixel voneinander entfernt. Wir müssen mit dem Cursor also mit jedem Menüpunkt 18 Pixel runtergehen (nicht vergessen: bei GMS2 ist (0,0) oben links und größere y-Werte bedeuten Schritte nach unten). Der Ausdruck 18*cursor tut genau dies! Wenn wir beim Menupunkt "Start" sind, hat die variable cursor einen Wert von 0 und damit addieren wir nix zur ursprünglichen Position des Cursors (wie wir auch wollen!). Mit cursor = 1 sind es 18 Pixel und mit cursor = 2 sind es 36 Pixel. Pfiffig!
Lasst uns nun auf Play drücken und dann Ergebnis unserer Arbeit anschauen! Ich habe dies mal als gif aufgenommen und wild auf den Tasten rumgedrückt:
Es funktioniert! Aber: es ist zu schnell! Warum? Die Antwort liegt im Step-Event. Wir überprüfen jeden Frame (bei uns aktuell: 30 frames pro Sekunde), ob die Taste gedrückt ist und das führt zu einem irrsinnigem Tempo (halt 30 mal pro Sekunde!). Hinweis an dieser Stelle: ihr seid beim GMS2 nicht auf 30 frames beschränkt und könnt auch auf 60 fps oder höher gehen. Dann wird der Code im Step-Event aber 60 mal pro Sekunde abgefragt (wie ihr seht: doppelte Leistung erforderlich).
Wir müssen also GMS2 beibringen, dass er unsere Taste nicht bei jedem Step abfragt, damit es nicht zu schnell wird! Aus diesem Grund werden wir als letzten Teil unserer Lektion einen Alarm bauen.
Fangen wir beim Create-Event unseres Objekts an, dieses modifizieren wir nun! Wir initiieren eine neue Variable, sie heißt pressed. In ihr speichern wir die Information, ob eine Taste gedrückt wurde oder noch nicht. Am Anfang ist natürlich keine Taste gedrückt, wir schreiben also hin: pressed = false;
Als nächstes gehen wir zum Step-Event. Folgende Änderung nehmen wir vor:
WIr überprüfen, bevor wir den Cursor nach unten bewegen über cursor++; nicht nur, ob down_key stimmt sondern prüfen auch, dass keine Taste vorher gedrückt wurde, über die pressed-Variable. Folgendes passiert nun: wenn pressed gleich false ist und die Taste nach unten gedrückt wurde, bewegt sich der Cursor nach unten UND die variable pressed wird auf true gesetzt. Wenn wir nun die Taste weiterhin gedrückt haben und das if-statement im nächsten Step nochmal abgefragt wird, dann wird der Code nicht ausgelöst, da die variable pressed nun true ist! Im Endeffekt bedeutet es: Man kann die Taste nur einmal bewegen, danach reagiert das System nicht mehr durch Cursorverschiebung. Das wollen wir nicht, deswegen führen wir einen Alarm ein. Wir schreiben alarm[0] = 5;, das bedeutet, dass der Code im alarm[0]-Event nach 5 steps/frames einmal ausgeführt wird. Und was schreiben wir in alarm[0]-Event rein? Folgenden Code, nachdem wir alarm[0] über Add Event eingefügt haben:
Was passiert im alarm[0]-Event? Wir setzen pressed wieder auf false. Im Endeffekt bedeutet das jetzt: das if-Statement wird, wenn es einmal ausgelöst wurde, erst nach 5 Frames wieder ausgelöst werden können! Wir haben jetzt einen Code, der bei Tastendruck nach unten nicht jedem Frame nach unten springt sondern nur jeden fünften! Das sieht als gif so aus:
Und damit beenden wir Lektion 2 und haben einiges über Skripte, Variablen und Alarms gelernt... und können unseren wunderschönen Herzcursor auf und ab bewegen!
Freue mich über eure Kommentare/Feedback und bis nächste Woche!
Berechtigungen
Zitieren
"Wolfenhain" fertig. "Endzeit": fertig. Neues Projekt: "Nachbarlicht" 
