Draw anstatt step.

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

  • Draw anstatt step.

    Hi, ich habe mal kurz eine technische frage:

    Warum sollte ich überhaupt das step-event verwenden?

    Ich habe einige befehle im draw event stehen und kann auch Funktionen im drawevent starten die eigentlich ins step gehören.

    Jetzt habe ich komplette verhaltensstrukturen von Gegnern im drawevent stehen und es funktioniert wunderbar. Jetzt frage ich mich: warum überhaupt step verwenden?

    Kostet das drawevent mehr Leistung?
    Oder welche Argumente habt ihr dagegen?


    Lg


  • Das Step event ist aus gutem Grund getrennt vom Draw-Event.
    Nehmen wir mal an, Du möchtest dass dein Spieler alle 10 Steps einen Punkt Gesundheit regeneriert.
    Du machst das Ganze im Drawevent. Nun hat der Spieler noch eine andere rechenintensive Sache auf, weshalb der Rechner ins Stocken gerät, die FPS gehen in den Keller und das draw-Event wird seltener aufgerufen.
    Schon ist dein Spieler wegen äusserer Einflüsse benachteiligt, da er langsamer heilt.
    Umgekehrt kann es aber auch passieren: Der Spieler hat VSYNC aus und sein Rechner ist eine wahre Höllenmaschine, die mit mehreren hundert FPS rendert. Hier wird der Spieler rasend schnell geheilt.
    Selbiges gilt für alles was einen Zeitverlauf besitzt - Bewegungen, Respawnzeiten, etc. pp
    Daher gibt es das Step-event. Du legst eine Ablaufgeschwindigkeit fest und das Stepevent wird exakt sooft aufgerufen wie es nach der verstrichenen Zeit nötig wäre. Selbst wenn die Grafik hinterher lagt, entsteht dem Spieler kein Nachteil und auch kein Vorteil im umgekehrten Fall.

    Zudem hat es auch was mit Kapselung und gutem Stil zu tun. Dinge die nicht mit der Grafik vergesellschaftet sind haben in der Zeichenroutine auch nichts verloren. Ansonsten produziert man nämlich ruck-Zuck Spaghetti-code (mit Fleischbällchen, aber dennoch).
  • @ blade runner

    Die probleme kann man ja umgehen indem man roomspeed multipliziert oder nicht?

    Was die Übersichtlichkeit betrifft finde ich es sogar besser alles im drawevent zu haben.

    Wenn ich jetzt Kollisionen z.B. definiere dann muss ich ja zwischen Step und drawevent hin und her switchen um festzulegen was passieren soll und wie das optisch aussehen soll. Also 2 scripts für etwas das ich unter Umständen in 5 Zeilen lösen könnte.

    Wenn es Performance kostet dann ist meine Frage gelöst, aber wenns um Übersichtlichkeit geht dann hab ich lieber alles was eine bestimmte Sache betrifft zusammen.


  • "room_speed" schrieb:

    This variable holds the running speed of the current room. Note
    that this is NOT the FPS (frames per second) but rather the
    number of game steps that GameMaker: Studio will try to
    maintain each second.

    Die Anleitung sagt: Nein, multiplizieren geht nicht, denn du weisst bei draw nicht wieviele Steps vergangen sind. Daher wird das zum Hazard-Spiel. Meist wird es gut gehen, aber manchmal fährst Du voll gegen die Wand.
    ansonsten frisst der Code in egal welchem Event die gleiche Menge an Zyklen. Es ist nur die Trennung anhand logischer (und paradigmenbedingter) Faktoren, die hier den Unterschied macht.
  • Natürlich kannst du die Spiellogik (wie kollisionsprüfungen oder AI) im draw-event stehen haben. Keiner hällt dich davon ab.
    Allerdings musst du dir bewusst sein dass der GM das step und draw-event intern in bestimmten Szenarios unterschiedlich handhaben wird.

    Beispielsweise kannst du mit draw_enable_drawevent() das automatische ausführen aller draw-events von objekten deaktivieren. (Wenn du z.B diese manuell ausführen/zeichnen möchtest.)
    Wenn die Spiellogik im Draw event steht, wird diese dann auch nicht mehr ausgeführt.
    Zusätzlich gibt es da noch die eigenheit dass der GM bei mehreren aktiven Views (nehmen wir mal an es gibt N views, wobei N die anzahl der aktiven views ist) jedes draw-event pro step N mal ausführen um jedes Instanz in den jeweiligen views zu rendern.
    Wenn du da weiterhin die Spiellogik im Draw-event haben wirst dann wird diese auch N mal ausgeführt, was aber nicht erwünscht ist.

    Ich kann generell aus Erfahrung sprechen dass die trennung von Systemen (logik, AI, rendering) auf lange sicht Sinn macht. Anfangs wirst du vielleicht anderer Meinung sein (kleinere Projekte oder Projekte im Anfangsstadium haben das Problem nicht da die Codebasis noch klein und überschaubar ist) aber sobald die codecomplexität und der Umfang steigt wirst du mit unübersichtlichen spaghetticode enden mit dem man schwer arbeiten können wird. (Der GM hat da ein generelles Problem aufgrund der kompletten abwesenheit von OOP Ansätzen wie richtige Klassen, Funktionen, Abkapselung, access modifiers, etc... aber das ist wiederum ein eigenes Thema.)

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

  • Ok verstehe. Ich werde also ein zwischending verfolgen: da ich zum Beispiel Menüs komplett drawen lasse, würde ich die Funktion weiterhin darin definieren. Nur im Spiel selber werde ich das vorsichtiger angehen.

    Das der GM ein übersichtsproblem hat ist leider tatsächlich ziemlich nervig. Was ich auch vermisse ist eine gliederungsfunktion in der du ganze Absätze von Code einfach einklappen kannst. Mit bissle Glück wird da ja nachgebessert.

    Danke.


  • glim888 schrieb:

    Funktionen kann man doch so halbwegs über

    GML-Quellcode

    1. with(obj_fish)
    2. {
    3. event_user(0);
    4. }


    realisieren?
    oder?


    Nein, am ehesten kommst Du mit Scripten und script_execute zur Funktionalität von Funktionen, da Du hier gekapselte Daten und eine Parameterübergabe haben kannst.
    Dein Codebeispiel ist das durchiterieren durch eine Objektliste.

  • Du musst deinen Code nicht komplett in ein "Run Script" Action packen. Du kannst auch mehrere nacheinander in zb. Das Step Event packen. Die werden nacheinander aufgerufen, als wären sie in einem Codeblock.

    Die vers. "Run Script" Actions kannst du auch benennen. Wenn du in der ersten Zeile auskommentierst mit zb. "///Steuerung". Dann erscheint das in der Übersicht so.

    Das ist schon ne ganze Ecke übersichtlicher als alles in eine "Run Script" Action zu packen.

    Edit: Siehe Anhang
    Bilder
    • gmd1.png

      22,54 kB, 772×395, 290 mal angesehen
  • Ich weiß jetzt nicht an wen das ging, aber das würde ich so nicht machen. Ich benutze die scriptfunktion die dann links im Baum angezeigt werden. Ich will vermeiden die einzelnen objekte zu durchsuchen.

    Ich gehe also so vor, dass ich ein Script erstelle mit dem Namen scr_spieler_create. Ist das Script offen dann füge ich mit dem +Symbol weitere hinzu für Step draw etc. Die werden dann im Baum als ein Script angezeigt. Dann erst erstelle ich das Objekt und weise direkt die Scripte zu den events zu. Dadurch muss ich das Objekt nurnoch anfassen wenn ich ein event hinzufügen will.

    Das was du da vorschlägst gefällt mir deshalb nicht, weil ich manschmal nicht gleich weiß in welchem Objekt sich welche Steuerung befindet. Und bei dir müsste ich jetzt jedes Objekt das in Frage kommt öffnen und überprüfen. Mit den externen Scripts geht das viel schneller. Ich forciere aber auch ein recht ausgeprägtes kommentierverhalten.

    vielleicht als Tipp für den ein oder anderen neuen leser: f2 taste > Pfeil oben taste und enter dann habt ihr nen hauptkommentierer erstellt. Geht fix und ist praktisch


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

  • War als Tipp gedacht, weil du die Übersichtlichkeit von GM:S beanstandet hattest.

    Aber ist hinfällig, wenn du das meiste über selbst erstelle Scripts erledigst ja :)

    Man kann diese ja auch noch in vers. Ordner packen um etwas die Übersicht zu wahren.