Programmierstil

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Programmierstil

      Welchen Programmierstiel bevorzugt ihr? 42
      1.  
        mehr Skripte, weniger Objekt intern, globale Variablen vermeiden (10) 24%
      2.  
        weniger Skripte, mehr Objekt intern, globale Variablen vermeiden (3) 7%
      3.  
        mehr Skripte, weniger Objekt intern, globale Variablen verwenden (16) 38%
      4.  
        weniger Skripte, mehr Objekt intern, globale Variablen verwenden (13) 31%
      Jo hoihoi!

      Ich weiß nicht wies Euch geht, ich jedenfalls hab so meine Probleme mit dem Finden eines guten Programmierstiels in GML.

      Zum einen wären da die globalen Variablen: im Informatikunterricht wurde mir damals immer und immer wieder eingeprägt globale Variablen zu vermeiden. Ein Lehrer traute sich sogar zu behaupten, dass globale Variablen "der Tod für jeden Programmierer" seien. Ich persönlich versuche mich so gut es geht daran zu halten. Jedoch bei Variablen wie z.B. global.GameSpeed oder dergleichen kommt es mir dann doch etwas hirnrissig vor, über ein Controller-Objekt darauf zu greifen zu müssen.

      Des weiteren bin ich mir immer unschlüssig wie ich meinen Code implementieren soll: alles in Skripte packen und diese vom Objekt nur aufrufen lassen, oder doch alles im Objekt internen Editor implementieren. Bei zahlreichen Skripten verliere ich immer schnell den Überblick, jedoch fehlt beim Objekt internen Editor die Möglichkeit mehrere Codes nebeneinander zu vergleichen...

      Ich finde ja, dass ein mießer/unsauberer Programmierstiel einer der größten Motivationskiller ist.

      Wie seht Ihr das? Welchen Stiel verwendet Ihr?
      "Es gibt nie ein glückliches Ende, denn es endet nichts." - Schmendrick
    • Das mit den globalen Variablen stimmt schon so, finde ich. Vor allem wenn das Projekt etwas größer wird und man nicht mehr die Übersicht über alle verwendeten Variablen, Funktionen etc hat könnte es leicht passieren, dass man in einem Objekt eine lokale Variable verwendet, die eigentlich schon global ist. Natürlich macht es in manchen Fällen mehr Sinn, wenn Variablen global sind, jedoch sollte man sehr sparen und ausdrückliche Namen geben, die man sicher nicht zufällig nochmal verwendet.

      Code in Scripts abzulagern hat eigentlich nur Vorteile: Sobald du ein Script öfter benötigst, macht es schon Sinn es auszulagern, denn solltest du mal etwas daran ändern müssen, musst du in allen Objekten und Events das jeweilige Script ändern (was bei einem großen Umfang zu Übersehen und Fehlern führen kann). Außerdem hast du die Möglichkeit, Argumente zu übergeben und der wiederverwendungswert ist relativ groß. So versuche ich z.B. immer, meine Scripts möglich anwendungsunspezifisch zu schreiben, damit ich sie später in anderen Spielen wiederverwenden kann.

      Unsauberer Code ist meistens der grund, warum man mit lange geführten Projekten aufhört: Man weiß einfach nicht mehr, was man damals verzapft hat (Blick zu Soul Reaver :D).

      © 2008 by Teamgrill Productions
    • Das mit den globalen Variablen hab ich auch schon öfters gelesen. Ich denke, dass das im GM nicht so wichtig ist, da da ja eigentlich alles relativ übersichtlich ist. In anderen Sprachen, z.B. C/C++,Python,... ist es ja so, dass du ja nur ein einziges Skript hast, in dem du alle anderen Funktionen Coden musst. Da kann die Übersichtlichkeit stark eingeschränkt werden, wobei manchmal Fehler durch unabsichtliches verändern von Variablen kommen, da man vielleicht vergessen hat, dass diese Variable global ist. Wobei das auch nur passiert, wenn das Projekt ziemlich groß ist. Bei so kleinen Sachen, sollte sowas eigentlich nicht passieren.

      Ich würde lieber Skripte nehmen und die dann einfügen, oder ein Skript machen, das die Objekte zu Anfang des Programms erstellt und ihnen die entsprechenden Skripte zuordnet.
      Das hat den Vorteil,
      1. dass du mehrere nebeneinander offen haben kannst. In manchen Situationen ist sowas eigentlich ganz praktisch.
      2. du kannst sie extern lagern und wenn du ein Update machst musst du nicht die komplette exe immer neu updaten, sondern nur die entsprechenden Skripte
      3. dass es (meiner Meinung) übersichtlicher ist, da du einzelne Abschnitte die eigentlich gar nicht zusammen gehören, getrennt "lagern" kannst, und nicht alles in ein Event reinklatschen musst und wenn du dann etwas suchst, dass du dann erst ewig suchen musst ^^.
    • Was ich dir auf jeden Fall empfehlen würde, ist die Tatsache, dass man wenige Objekte mit vielen Aufgaben verwenden sollte, da es andersrum einfach nur performance frisst. Das merke ich vorallem bei meinem 2004er Rechner. Das liegt aber eher am Game-Maker, der mit der Referenzierung der Objekte anders umgehnt als ein selbst programmiertes Spiel/Programm.

      mfg Biochemic
      ////////////////////////////////////////////////////////////////////////////////////////////////
    • @marvin: Wie wärs mit Iron Python oder N++ ? Die beiden Entwicklungsumgebungen sind ziemlich übersichtlich.
      Da kannst du die einzelnen Funktionen auch in einfach Skripten lagern.

      Zum Thema:
      Objekte und Scripts benutze ich zu Hauf. Globale Variablen ebenfalls häufig.
      Spätestens wenn man mit den 3D-Funktionen des GM arbeitet macht es Sinn, Skripte zu benutzen,
      da man Teile vom Code immer wieder braucht.

      Mein Programmierstil ist Performance-orientiert:
      Maximum an grafischer Schönheit und Maximum an FPS.
      Oft 60 FPS. Bei Projekten, bei denen die Grafik 60% ausmacht(3D FTW!)
      30 oder 40 FPS(Mehr als 40 Bilder pro Sekunde kann das menschliche Auge nicht wahrnehmen).

      Meine einzige, schlechte Angewohnheit beim Programmieren(In meinen Augen)
      ist, dass ich zu viele Objekte mache, was mir immer wieder die konstanten 30 FPS versaut.

      Ich bin eher Typ 3...
    • Also für Multiplayer Spiele hab ich mir früher immer ein persistentes Objekt MSG angelegt, welches alle Nachrichten-IDs beinhaltet hatte. So konnte ich dann einfach immer MSG.ITEM_PICKUP schreiben, anstelle von global.MSG_ITEM_PICKUP. Und wenn ich IDs hinzufügen oder ändern will, dann bearbeite ich einfach das Create Event von dem Objekt.
      Das gleiche hab ich auch auf meinen Sprachwechsler angewendet, ein Objekt pro Sprache, dann eines davon in einer globalen Variable (besser noch globalvar) speichern:

      GML-Quellcode

      1. global.language = GER;
      2. show_message(global.language.TEAM_RED);

      Mein Programmierstil wäre dann wohl ziemlich gemischt. Ich mach einfach, was bequem, leicht zu bearbeiten und schnell geht. Ich hab viele Objekte, viel Code in Objekten, aber auch sehr viel in Skripten ausgelagert. Allerdings ist das teilweise schon Jahre her, heute würde ich bestimmt noch etwas mehr in Skripte stecken.


      Globale Variablen verwende ich relativ selten, nur wenn es nötig ist. (Beispiel: global.room_w )

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von copyboy ()

    • Für den GM gilt:
      - Viele Instanzen vermeiden. Jedes Event, selbst wenn es nie ausgeführt wird (z.b. Kollisionen), machen eine Instanz noch rechenintensiver.
      - Globale Variablen vermeiden. Jede Instanz bekommt eine Kopie aller globalen Variablen.

      Viele Skripte sollten harmlos sein. Ich persönlich begnüg mich immer mit einer Handvoll Objekte und deren Instanzen und regel soviel ich kann über Code.


      Ferner sollte man im GM Room Creation und Instance Creation Code vermeiden, da diese sich nur schwierig finden lassen.


      Edit:
      Da ich schon gefragt wurde: Die Info mit den globalen Variablen stammt aus 4.0er-Zeiten von Mark selbst. In der aktuellen Hilfe findet sich noch der Satz
      Sometimes you want variables only within the current piece of code or script. In this way you avoid wasting memory and you are sure there is no naming conflict. It is also faster than using global variables
      .
      Ob das ein Überbleibsel der alten Warnung ist oder nach wie vor einen Rückschluss auf eine solche Handhabung zulässt, kann ich nicht sagen.
    • Mr. Diesel schrieb:

      30 oder 40 FPS(Mehr als 40 Bilder pro Sekunde kann das menschliche Auge nicht wahrnehmen).
      Falsch, der Mensch kann pro Auge 30 Bilder in der Sekunde wahrnehmen
      Deswegen wird für die bestmögliche 3D Darstellung 60 Bilder pro sekunde benötigt . Für jedes Auge 30 Bilder.
      Spoiler anzeigen

      Empfohlen wird 60 Bilder pro Sekunde aufgrund der Performance.
      Viele glauben immer wieder, Ruckler usw kommen davon weil sie zu geringe bilder pro sekunde haben. Ein flüssiges Spiel kann aber auch mit 15fps erreicht werden. Ruckler werden deswegen wahrgenommen weil kurz vielleicht 50 bilder pro sekunde gezeigt werden und plötzlich nur noch 25. Hieße, wenn ein Spiel mit 120fps läuft. und plötzlich auf 70 fällt nehmen wir das nicht als ruckler war. erst wenn es unter 60 fällt.


      Achja ^^, zu den Variablen. gibt es in "Nicht Klassenbasierten" Programmiersprachen überhaupt interne Variablen?.
      Meiner Meinung nach. Wer sauber programmiert, sollte rein globale Variablen nutzen. Wer nicht, so oft wie möglich interne um konflikte zu vermeiden.
      Zu den Objekten, soweit ich weiß muss der GM ja jedem Objekt eine ID (Datenbank) zuteilen. Diese zu speichern und aufzurufen verbraucht Leistung und Arbeitsspeicher. Bin mir aber hier nicht sicher.

      LG. C5_booster
    • W00t? Jede Instance bekommt eine Kopie der Variable und alle Events, auch wenn sie nicht ausgeführt werden, blocken???
      :rage:

      Ok. Ab jetzt arbeite ich anders^^

      @CS_Booster:
      Wir liegen beide falsch: Zwischen 60 und 65 - Im Durchschnitt 62 :D
      Aber das Gehirn kann 20-30 davon nicht verarbeiten.
    • Mr. Diesel schrieb:

      W00t? Jede Instance bekommt eine Kopie der Variable und alle Events, auch wenn sie nicht ausgeführt werden, blocken???
      :rage:

      Nimm mal dein Wandobjekt (oder irgendetwas, was pro Raum 100+ mal instanziert wird) und füge eine Kollisionsevent mit einem leeren Script ein. Deine Framerate sollte stark runtergehen. Denn selbst wenn der Code leer ist, werden dann für all diese Instanzen Kollisionsüberprüfungen gemacht.
    • @Mr.Diesel
      ok ^^,

      Jetzt mit voller geballten Meinung.
      Benutzt so oft wie möglich interne Variablen. Warum? Weil der GM dafür gemacht wurde. Wenn ihr auf rein Globale Variablen setzen wollt wechselt in eine andere Programmiersprache die sowieso nur dessen zuläst.
      Anderseits sollten so wenig Variablen wie möglich verwendet werden. Wohl deswegen weil jeder Wert eine ID bekommt. Um so mehr Variablen umso länger muss der Computer in der Datenbank nach der ID suchen. Weil das nur schnell geht wenn die Datenbank in den Arbeitsspeicher geladen wird heißt Mehr Ram verbrauch. Zwar liegt der selbst bei ungefähr 100 Variablen bei nicht mal 1mb. :D, aber größere Spiele die Aray´s nutzen wo es auf mehrene Millionen kommt z.b (Collisionsabfrage in 3D Spielen) ist das ganzschön etwas.
      (Das von mir geschriebene ist meine meinung und muss nicht realität sein oder werden und beruht auf Fakten!!!)
    • Kleine Ergänzung zu meinem Skript-Problem:
      Ich habe mich mittlerweile dermaßen in das "Möglichst-nur-Skripte-verwenden-Konzept" hineingesteigert, dass ich für jeden einzelnen Codeschnipsel ein eigenes Skript anfertige, und dieses dann im entsprechenden Event aufrufe.
      z.B.:
      Spoiler anzeigen
      //scr_obj1_init
      var1 = 1;
      var2 = 2;
      var3 = 3;

      //obj1 :event_create:
      :action_script: scr_obj1_init

      Bei den ganzen Haufen Skripten verlier ich leicht den Überblick (@copyboy: Respekt wenn du dich da noch auskennst :huh: )

      @marvin:
      deine Idee, die Objekte durch Skripte erstellen zu lassen find ich super! :thumbsup:

      @copyboy:
      Das mit dem MSG-Objekt hab ich nicht ganz verstanden :?:
      Um auf die Variablen des MSG-Objektes zugreifen zu können musst du ja eine Instanz des Objektes erstellen. Von dieser giebst du dann die ID an die anderen Objekte/Instanzen weiter, oder? Weist du dann jedem anderen Objekt mit

      Quellcode

      1. msg_id = instance_find(obj_msg, 1);

      oder ähnlichem, die ID des MSG-Objektes einer lokalen Variable zu?
      "Es gibt nie ein glückliches Ende, denn es endet nichts." - Schmendrick
    • Klaus C. Haber schrieb:

      Ich habe mich mittlerweile dermaßen in das "Möglichst-nur-Skripte-verwenden-Konzept" hineingesteigert, dass ich für jeden einzelnen Codeschnipsel ein eigenes Skript anfertige, und dieses dann im entsprechenden Event aufrufe.
      Ok, das ist ein bisschen schwachsinnig ^^
      Besser wäre es, wenn du Skripts in Events anlegst, also z.B.:
      player_create
      player_step

      Wenn du dann im Step-Event meherer Code Abschnitte hast, z.B. die Steuerung, dann würde ich die auch in ein eigenes machen, aber nicht jede einzelne Variablen deklaration ^^
    • Klaus C. Haber schrieb:

      @copyboy:
      Das mit dem MSG-Objekt hab ich nicht ganz verstanden :?:
      Um auf die Variablen des MSG-Objektes zugreifen zu können musst du ja eine Instanz des Objektes erstellen. Von dieser giebst du dann die ID an die anderen Objekte/Instanzen weiter, oder? Weist du dann jedem anderen Objekt mit

      Quellcode

      1. msg_id = instance_find(obj_msg, 1);

      oder ähnlichem, die ID des MSG-Objektes einer lokalen Variable zu?
      Ja und nein. Ja, ich hab eine persistente Instanz, nein - und wie kommst du überhaupt darauf? - ich benutze einfach nur den Namen des Objektes. Beispiel:

      GML-Quellcode

      1. clearbuffer();
      2. writebyte(MSG.JOIN);
      3. writestring(name);
      4. scr_send2all();

      Ich finde nicht wirklich, dass es die beste Lösung ist und der Performance tut es auch nicht gut - wobei es auf keinen Fall ein Performance-"Fresser" ist, aber es war bequem und sieht im Code schön aus.