Technik und Übungen...

[Linksawakening]

Ich würde sagen, dass das stark abhängig davon ist, was du bereits weisst/kannst
Generell sollte man (so hab ich das gemacht) immer versuchen das umzusetzen, was man tatsächlich braucht ^^

Ich persönlich habe einfach kleinere Lernprojekte gestartet und mit vorher überlegt, was genau ich erreichen will (nicht wie, das kam später :P)
Dann habe ich angefangen und geschaut, wie weit ich mit dem komme das ich bereits kann. Wenn man dann irgendwann an einen Punkt kommt an dem man
nicht wirklich weiss wie es funktionieren kann, gibt es 2 Möglichkeiten: a) ins Forum gehen, fragen, Antwort bekommen, umsetzen; oder b) (finde ich persönlich viel hilfreicher) rumprobieren und das so lange,
bis sich ein Ergebnis aufzeigt welches zufrieden stellend ist ^^
Wenn man dann ein Ergebnis hat, und somit eine grobe Idee wie es funktionieren kann, kann man dann immer noch ins Forum gehen, seinen Weg präsentieren und dann schauen, ob es eventuell noch
andere Wege gibt es zu realisieren.
Hintergrund von Weg b) und warum ich ihn präferiere: Man weiss bereits wie es funktioniert, und wenn man dann einen alternativen Weg gezeigt bekommt, ist es einfacher diesen nachzuvollziehen

Hoffe das war einigermaßen hilfreich, viel Spaß beim ausprobieren und weiterentwickeln

[Drakee]

Das Problem, das du leider in Angriff nehmen musst, ist genau das selbe wie mit Programmiersprachen: Du musst lernen, wie die Engine "denkt und versteht". Prinzipiell ist das Eventscripting des Makers strukturell das Selbe in Grün wie eine Programmiersprache, nur leider halt mit sehr vielen Limitierungen und weniger "Features". Für fortgeschrittene Eventskripts bedarf es der selben Art zu denken wie bei richtigen Programmiersprachen. Ich persönlich arbeite sehr viel mit Pointern und Schleifen, provisorisch im Variablen Array unterteilte Intervalle als eigene Arrays für bestimmte Dinge, wie z.B. ein Itemmenü oder auch Sortieralgorithmen, um automatisierte Algorithmen zu skripten.

Als ich angefangen habe, habe ich hauptsächlich Skripte aus anderen Games kopiert. Mein Bruder hat mich damals auf den RPG Maker gebracht und genauso wie bei ihm, hat mich der RPG Maker für die Zukunft vorbereitet. Indem ich mich damit auseinandergesetzt habe, habe ich das Gefühl für's richtige Programmieren bekommen. Mein Bruder arbeitet jetzt übrigens in Hamburg für einen ungefähren Bruttolohn von 4k als Spieleentwickler Und ich studiere Informatik.

Ich habe nicht vor dem RPG Maker mit Programmiersprachen angefangen und im RPG Maker zunächst, wie gesagt, Skripte kopiert, ohne die zu verstehen, oder meinen Bruder welche skripten lassen. Ich selbst habe irgendwann angefangen selbst nachzudenken und meine eigenen Skripte überlegt und umgesetzt. Es liegen 14 Jahre Makererfahrung hinter mir und es ist bei mir, denke ich, immernoch Luft nach oben, wobei ich zwischendurch auch sehr viele Auszeiten vom Maker hatte.

Wichtig ist bei der Skripterstellung, dass man weiß, was das Skript machen soll und dann muss man sich erstmal Pseudocode überlegen. Pseudocode ist nichts anderes als eine allgemeine Anleitung, die du einer Person erklären würdest, z.B.

Wenn die Sonne scheint,
dann geh raus
sonst,
mach das Fenster zu.

Nach dem Pseudocode kommt dann die Umsetzung in richtigem Code oder Eventskript, natürlich unter Berücksichtigung der Syntax und Funktionsweise des Makers.

Sonst schau doch mal durch Tutorials! Die gibt es heutzutage Zuhauf

[Leana]

Eine gute Lernmethode stellt der Code anderer dar. Ich habe zunächst verschiedene Skripte von dieser Seite ausprobiert und sie je nach Lust und Laune mal mehr, mal weniger geändert. Irgendwann hab ich dann angefangen, gezielt die Wirkung gewisser Befehle auszuprobieren, z.B. die Move-Event-Befehle. Enorm weitergebracht haben mich auch die Betatests, die ich bei anderen gemacht habe. Da lerne ich auch heute noch immer was dazu

[BDraw]

Eine gute Lernmethode stellt der Code anderer dar. Ich habe zunächst verschiedene Skripte von dieser Seite ausprobiert und sie je nach Lust und Laune mal mehr, mal weniger geändert. Irgendwann hab ich dann angefangen, gezielt die Wirkung gewisser Befehle auszuprobieren, z.B. die Move-Event-Befehle. Enorm weitergebracht haben mich auch die Betatests, die ich bei anderen gemacht habe. Da lerne ich auch heute noch immer was dazu

...

Kann ich bestätigen, bloß dass ich damals VD2 auseinandergenommen habe, angefangen beim Ringmenü und dem Hinterherlaufen oder den Fußstapfen in Schneegebieten. Eben Sachen die nicht allzu riesig waren, die ich aber damals toll fand und nachbauen wollte.
Die große Hürde bei der ganzen Maker-Technik sind eigentlich Variablen, Switches und Schleifen/Labels. Wenn man die mal grob verstanden hat ist die Grundlage für alles weitere eigentlich da.

[MagicMaker]

Mir steht die Frage im Sinn wie ihr technisch begonnen habt mit der Technik des Makers (ich bevorzuge den Rm2K) umzugehen.

...

Ich habe damals mit jemandem an Dreamland 3 herum-debuggt, weil die Rätsel und Mechaniken
so endlos grauenvoll waren und bekam gesagt, was Switches und solche Sachen eigentlich sind,
beim Rest im Erlernen und Anwenden der Basics war ich ziemlich auf mich alleine gestellt.

Und die ersten Ergebnisse werden auch mit großer Wahrscheinlichkeit schlimm werden, wenn man
gerade erst bei Programmlogik anfängt durchzusteigen, dafür hat man ein paar Jahre später was an
dem eigenen alten Mist zu lachen, wenn man dranbleibt.

Übungen bei mir, irgendwie mit der Technik vertrauter zu werden, bestanden und bestehen eigentlich
immer daraus, dass mir irgendwas einfällt oder woanders sehe, das ich dann mal spontan entschließe,
selber zu basteln, möglichst ohne fremden Code schon vor mir zu haben. Das kann zu einer sehr gut
gefüllten virtuellen Abstellkammer nie fertig entwickelter oder vielleicht gar fertiggebauter aber nie in
was größerem genutzter Dinge mutieren, was aber nicht so negativ ist, wie es sich vielleicht anhört.

Aus Tutorials und Sachen zum Nachbauen wie dem Zeug im F-eBook hingegen hab ich nie wirklich
viel gelernt außer einiger Details, die ich aber auch teilweise eigentlich hätte aus dem Matheunterricht
mitbringen können (siehe z.B. Zerlegen von Zahlen in ihre Ziffern durch Restrechnung).