Ich würde ja sagen, dass weder 60 fps noch No Lag Script Pflichtdinge sind. Ich gehe sogar soweit und sage, dass man beides nicht verwenden sollte, sofern man die Möglichkeit dazu hat.
Nicht dass die Skripte schlecht sind, keineswegs, aber sie bringen meiner Meinung nach mehr Nach- als Vorteile.

Das No Lag Script (sofern wir vom Selben reden) überspringt während dem Logikupdate Events, die außerhalb des Bildschirms liegen. Du willst ein Event außerhalb des Bildschirms bewegen? Zu doof, funktioniert nicht, weil das Script dieses Event nicht aktualisiert.
Außer natürlich, du hast irgendeinen komischen Tag in den Eventnamen geschrieben. Aber auch das ist extra Arbeit, die man leider gerne mal vergisst...dann wird das Fehlersuchen zum Grauen.
Gut, das lag eher an mir und nich am Skript Es hat aber dafür gesorgt, dass ich das Skript recht schnell wieder aus meinen Projekten entfernt habe.
Wenn man aber wirklich Performanceprobleme wegen zu vieler Events hat, sollte man eher die Ursache statt der Folge bekämpfen.
Man sollte eher folgendermaßen an das Problem herangehen:
Wieso habe ich so viele Events? Muss ich für mein Rätsel echt die ganze Karte mit Player Touch-Events zumüllen oder reicht nicht einfache ein Parallel Process-Event?
Müssen die Lichteffekte wirklich durch 100+ Events gelöst werden oder reicht nicht ein Show Picture?

Meiner Erfahrung nach kommt es zu Performance Problemen, wenn man zu viele copy+paste Events auf der Karte hat. Es ist besser zu lernen, diesen Arbeitsstil zu vermeiden als ein No Lag Script zu verwenden.
Wenn man zB später etwas ändern will, muss man bei der copy+paste Methode den Code für jedes Event ändern, besonders schlimm wenn jedes Event auch noch seine eigenen Variablen verwendet!
Benutzt man stattdessen z.B. nur ein Parallel Process-Event ist das debuggen, fixen, ändern etc viel einfacher!
Das Skript nicht zu verwenden zwingt einen dazu, performanter zu arbeiten. Das ist auf lange Sicht viel hilfreicher als das Skript.
No Lag Script ist also kein Pflichtding und sollte nur im Notfall verwendet werden, wenn nichts anderes mehr hilft.

Der Maker (der Editor) arbeitet standartmäßig mit 40 fps (logik: waits, duration etc arbeiten mit 20 fps). Effektiv kann man damit den Animationseditor in die Tonne klatschen, wenn man das Spiel mit 60 fps laufen lässt.
Im Spiel läuft die Animation dann nämlich um ein Drittel schneller, erstens sieht die Animation dann anders aus, zweitens ist sie nicht mehr mit dem Sounds synchron.
Klar, man kann die Animationen im Spiel testen, aber es ist unnötiger Aufwand. Es wird unnötig schwer, ordentliche Animationen herzustellen und das schlägt sich am Ende in deren Qualität nieder.

Ganz besonders sollte man bei Performance Problemen aber kein 60 fps Skript verwenden. Ansonsten schwankt die fps zu viel.
Wenn man auf der Karte weniger fps als im Kampf hat, werden die mühsälig an 60 fps angepassten Animationen auf der Karte zu langsam abgespielt und sind dann wieder nicht synchron zum Sound.
Und das kann man nicht fixen, indem man eine schnelle und kurze Animation für Kampf und Karte erstellt! Was auf dem eigenen PC zu langsam läuft, könnte bei anderen Spielern flüssig sein.
Insofern ist es wichtig die FPS immer konstant zu halten, damit jeder Spieler die gleiche Erfahrung hat. 60 fps also bitte nur, wenn man überhaupt keine Probleme mit der Performance hat - deshalb ist es alles andere als Pflicht.
Insbesondere sollte man nicht 60 fps erwarten, wenn man ein No Lag Script benötigt!



Aber ich möchte auch deine Frage beantworten, von daher ein Pflichtding von meiner Seite.
Wobei auch mein folgender Tipp nicht wirklich Pflicht genannt werden kann. Es ist eher ein Hinweis, der das Arbeiten um ein wesentliches vereinfachen... und je einfacher das arbeiten bzw finden/beheben von Fehlern, desto mehr Motivation hat man um die Qualität des Spieles zu halten (oder das Projekt überhaupt zu beenden ).

Mit dem Event Befehl Script und folgendem Code kann man andere Events starten:
Code:
$game_map.events[*eventID*].start
Richtig nützlich, wenn man eine längere Szene schreibt. Vor allem, wenn man dort auch noch Entscheidungen fällen kann.
Dann kannst du ein Event für den einen Szenenverlauf und ein Event für den anderen Szenenverlauf starten.

Das ganze hilft auch beim Starten von Szenen. Du kannst den Befehl verwenden, wenn du zB einen 5 Felder breiten Durchgang hast und eine Szene starten soll, wenn der Spieler hindurchläuft.
Anstatt dein Szene-Event 5 mal für jedes Feld zu erzeugen (böser copy paste Stil), oder Switches für ein Autostart-Event zu verschwenden, schreibst du das Event nur einmal. Die anderen 4 Felder starten dann einfach nur das erste Event.