Bei solch einem Code sollte man lieber auf die Leserlichkeit achten, sonst würden wir noch alle in Assembler programmieren.

= ist der Zuweisungsoperator, == ist der Vergleichoperator. In anderen Programmiersprachen ist dies so, nur beim GM wird kein Unterschied gemacht.




Es gibt eigentlich keinen großen Unterschied, wenn du willst kannst du eine Timer DLL benutzen und das ganze nachmessen.

Schreib sauberen, verständlichen und einheitlichen Code. Das ist viel wichtiger. Mach dir lieber Gedanken über wie oft was ausgeführt wird. Halte die Anzahl der Objekte und deren Events auf einem Minimum. Das sind die Sachen, die sichtlich die Performance beeinflussen.

Alte Experimente von mir haben gezeigt, dass das Parsen einzelnder Zeichen stärker ins Gewicht fällt als die meisten Funktionen. Würdest du also ernsthaft optimieren wollen, müsstest du sämtlichen Code in eine Zeile schreiben, Namen kurz halten und alle Kommentare löschen. Inwieweit sich das mit Studio geändert hat weiß ich nicht - immerhin wird es für diverse Plattformen zuerst in Javascript konvertiert, wobei auch ein klein wenig optimiert wird.

Kurz: Vergewaltige deinen Code nicht. Es bringt nichts. Für so verschachtelte Ifs bietet sich, wie schon von anderen angemerkt, switch an.


Edit: Aus deinem Profil schließe ich, dass du übers Programmieren schon mindestens eine Vorlesung gehört hast. Haben die dir da etwa nicht beigebracht, dass Spaghetti-Code eine der größten Sünden überhaupt ist?

Spielt keine Rolle, da der Create-Code so oder so sofort ausgeführt wird. Der Übersicht halber ist das Auslagern ins Create-Event aber vermutlich schlauer, da du später diese Objekte auch eventuell von woanders her erstellen willst und sonst den Code dorthin kopieren müsstest.

Im Game Maker wurder das früher zwar vernachlässigt, aber jede schlaue Sprache sollte nach dem ersten false abbrechen, wenn danach ein && kommt. In z.B. Lua kann man dies, glaube ich, sogar selbst bestimmen indem man & bzw. && benutzt.

Das macht keinen Unterschied denn es geht in keiner Weise darum wie viel Code einfach im Event steht sondern wieviel code ausgeführt wird. Also wenn der code aufgrund von if's eben nicht _jeden step_ ausgeführt wird, dann braucht dies auch keine Bearbeitungszeit.


Du hast das falsch verstanden. Was er meinte war wenn du sowas hast:



Wenn scripta falsch ausgibt, dann wird _dennoch_ auch scriptb ausgeführt und im Hintergrund verglichen. Es ist aber egal was script2 ausgibt, der //code wird dennoch nicht ausgeführt!
Es geht nur darum dass scriptb vieleicht viel Rechenzeit benötigt und man deshalb diese Konstruktion vermeiden sollte wenn es häufig vorkommen kann dass scripta false ausgibt.



EDIT: Zitat von MewX:

Alte Experimente von mir haben gezeigt, dass das Parsen einzelnder Zeichen stärker ins Gewicht fällt als die meisten Funktionen. Würdest du also ernsthaft optimieren wollen, müsstest du sämtlichen Code in eine Zeile schreiben, Namen kurz halten und alle Kommentare löschen. Inwieweit sich das mit Studio geändert hat weiß ich nicht - immerhin wird es für diverse Plattformen zuerst in Javascript konvertiert, wobei auch ein klein wenig optimiert wird.

Mit welcher GM-Version hast du das denn getestet?
Denn meines Wissens nach wandelt der GM ja beim "kompilieren" den Code in einen bytecode (der ja bei Laufzeit interpretiert wird) um. Dabei werden Komentare, etc automatisch übersprungen. (bzw. es wäre logisch dass dies geschieht).
So hatte es in meinen Tests auf jeden Fall keine Auswirkungen wie lang der Variablen-Name ist (selbst ein 5 Seiten füllender Name nicht ) und es werden scheinbar sogar konstante Ausdrücke berechnet.
Also sowas wie
D.h. solche Schönheitsfehler wirken sich nur auf die Kompilierzeit aus, nicht auf die Laufzeit.

Die beiden Varianten sind vom Ergebnis nicht gleich. Falls code 1 a verändert (zum Beispiel auf 2) stellt, kann auch eine weitere Anweisung (code 2) noch im selben Step ausgeführt werden. Die Richtige Variante 1 wäre also:

Ich hebe das deshalb hervor, weil es ein häufig gemachter Fehler ist und auch einer, den man leicht übersieht.
Die Vorteile und Nachteile von if und switch liegen woanders. Du kannst in einem switch schlecht a<1 abfragen und in viele if-Abfragen können schnell unübersichtlich werden und sehen eventuell in mit switch-case übersichtlicher aus.

Siehe Dragongamer.

Durch die Scripts wandern muss er immer. Entscheidend ist, was ausgewertet wird. Tatsächlich solltest du ihn aber wenn nur wegen meiner Begründung weiter oben auslagern. Ansonsten bietet sich immer noch an, große Codeblöcke in eigene Scripts auszulagern, aber auch hier mehr der Übersicht halber.
Ich bezweifle ganz stark, dass dir ein Codeblock, der nur gelesen aber nicht ausgeführt wird, irgendwann mal das Genick bricht.

Ich habe mal kurz das hier getestet:

Und siehe da, das Spiel beendet sich. Peinlich, peinlich. Für komplexere Abfragen solltest du also tatsächlich verschachteln.


Edit:
@Dragongamer GM5 oder 6, glaub ich. Studio sollte aber in Bytecode übersetzen, ja, aber es würde mich nicht wundern, wenn er darauf auf Win/Mac immer noch verzichtet.

Das habe ich gar nicht (mehr) gewusst. In anderen Programmiersprachen, C(++) und ich glaube auch Java zum Beispiel, wird der zweite Ausdruck gar nicht mehr ausgewertet. Wozu auch?
Gibt häufig im Code Abfragen, bei denen man das gerne verknüpfen können würde:
Das geht dann wohl nur verschachtelt:

Stimmt, das ist eine doofe Eigenheit des GM's. Mit if's kann man das aber ja leicht umgehen.. problematisch ist's nur wenn man ein else benutzen will welches sich auf beide Ausdrücke bezieht. Das geht dann nur mit einer Zwischenvariablen..

Auf die Idee bin ich noch gar nicht gekommen. Man lernt nie aus.

Dass ich das noch nie gesehen habe liegt wohl daran, dass es unter Java nicht funktionieren würde und ich in Java bisher am meisten geschrieben habe. Java will da ints oder enums haben.
Der eigentliche Witz ist, dass ich es bei deinem ersten Post (den ich zitiert habe) komplett übersehen habe und sofort im Kopf durch henrik1235s Variante ersetzt habe...