Suchergebnisse

Naja eine programmiertechnisch bessere Lösung gibt es eigentlich nicht. Wenn du ernsthaft an der Sache dran bist würde ich dir empfehlen jetzt in den sauren Apfel zu beißen, denn irgendwann ist es sowieso soweit. Dateistrukturen sind grundlegend und wenn du sie nicht beherrschst wirst du immer irgendetwas unperformantes basteln müssen, was dir auf lange Sicht nur mehr Zeit kostet, dich verwirrt und dir viele Sachen unerreichbar macht. Schreib doch lieber was du an dem Konzept nicht verstehst.

GML-Quellcode (25 Zeilen)

Habe auch nochmal editiert, hier alle Funktionen : docs.yoyogames.com/source/dadi…tures/ds grids/index.html Da gibts wohl bei ds_grid_get() einen Fehler in der Dokumentation vor x,y muss natürlich noch stehen welches grid referenziert wird. ds_ sind die erweiterten Dateistrukturen von GM, quasi so wie Arrays bzw bauen teilweise auf diesen auf, nur mit mehr funktionen. Wichtig ist, das man sie immer initialisieren sowie löschen muss, wenn sie nicht mehr benötigt werden(anders als es bei Arrays ge…

Ich gehe davon aus es geht um soetwas wie Schach. In diesem Fall würde ich das Spielfeld durch ein ds_grid darstellen. Somit kannst du in jedes Feld einen Index oder Instance ID speichern. GML-Quellcode (8 Zeilen) Dann eine Geschachtelte Forschleife im Drawevent um jedes Feld auszulesen und entsprechend zu malen. GML-Quellcode (7 Zeilen)

die Texturen brauchen eine gewisse (farb)-Tiefe wenn ihr kein bump mapping benutzen wollt dann wenigstens ambient occlusion, damit es nicht alles so unecht und oberflächlich erscheint. Desshalb sahen alte Konsolenspiele immer so "billig" aus, weil die hardware noch nicht stark genug war. Heutzutage sollte das aber jeder PC schaffen. de.wikipedia.org/wiki/Umgebungsverdeckung

Ambient Occlusion, Bloom, Lightshafts etc.. würden das Spiel schon ungeheuer aufwerten.

also wenn du ein par_bonusblock hast, dann packst du einfach in sein draw event meinen code und das alte mit visibility kommt ganz raus, die childs sollten dann nichts im draw event haben oder event_inherited() im drawcall aufrufen, wenn du es doch noch anderweitig nutzt. die HPZahlen können auch durch variablen ersetzt werden um dann verschiedenen childs unterschiedlich viel Leben zu geben.

Noch als Ergänzung: Visible sollte meines Erachtens nur für den Fall verwendet werden, wenn man ein Controllerobjekt oder ähnliches hat, dessen man ein Sprite zur Übersicht im Roomeditor zuweist, aber nicht will, das es grafisch im Spiel erscheint. Warum packst du nicht einfach eine Abfrage ins Drawevent GML-Quellcode (7 Zeilen) PS: self/id würde ich so nutzen "self.visible = true;" "id.visible = false;", also als Referenz nutzen. Das selbe funktioniert auch mit "with (self) {visible = true;}" "…

Ich habe die Fragestellung leider noch nicht ganz nachvollziehen können, aber wenn du wie ich verstanden habe 5 verschiedene Zahlen aus dem Pool 1-9 haben willst, so das jede Zahl nur einmal auftauchen kann, würde ich dir ds_list empfehlen. Denn abstrakter betrachtet kannst du da nicht nur die Zahlen von 1-9 Ablegen und sortieren/mischen sondern auch Objekte welche diese Zahlen repräsentieren sollen (grafisch). GML-Quellcode (17 Zeilen) Hier noch alle Funktionen NACHTRAG: nehmenwir an du speiche…

Ja es sollte if (throw && ...) und if (pickup && etc...) sein. Ausserdem sollte bei deiner Levelup Bedingung nicht xp = 0 sondern xp -= 5000; stehen. So wie es jetzt ist können Punkte verschwinden, zB wenn man 4995 xp hat und dann 50 dazubekommt.

eventuell kannst du auch einfach mit game_save("savegame.dat") und game_load("savegame.dat") arbeiten. Da wird dann ALLES gespeichert, ist also recht umfangreich und lange nicht die optimale Lösung, allerdings kannst du dann auch nichts vergessen zu speichern.

Guck mal hier ins Handbuch, ich möchte das du erstmal selbst den Kopf anstrengst: Listener: http://docs.yoyogames.com/source/dadiospice/002_reference/game assets/sounds/audio listeners.html und Emitter: http://docs.yoyogames.com/source/dadiospice/002_reference/game assets/sounds/audio emitters.html Damit lässt sich genau das anstellen was du willst, ohne das du es selbst berechnen musst.

Steht doch direkt über deinem Post, da brauchst du kein screen_safe.

es ist ja schon ein surface. GML-Quellcode (4 Zeilen) Wenn nicht mehr benötigt das surface mit surface_free wieder löschen.

Was spricht denn dagegen, direkt das application_surface zu duplizieren? Ansonsten kannst du alles mit ner while-Schleife und nem Dialog stoppen

Das heißt aber nicht, das es nicht geht oder nicht besser wäre die neue zu Benutzen. Die ist was umfangreicher, aber das was du beschreibst hätte man mit einem Emitter hinbekommen. Poste mal den Code dann kann ich gucken was ich für dich tun kann, ich lehne mich mal aus dem Fenster und sage das es kein großes Unterfangen ist.

Hier sind alle Funktionen des alten Audiosystems : docs.yoyogames.com/source/dadiospice/002_reference/game assets/sounds/legacy sound/index.html Es gibt aber eigentlich keinen Grund nicht das neue zu verwenden, kannst ja mal schreiben wieso es das Legacy sein muss. EDIT : Wenn du mit länge meinst, den Sound nach beliebiger Zeit anzuhalten, dann ja. Wenn du damit meinst, den Sound zu pitchen, dann nein. Das geht nur beim neuen System.

GML-Quellcode (1 Zeile)

Wenn du die Abfragen noch vertauschst ist es performanter^

Am besten wäre es wenn du das Mündungsfeuer nicht als einzelnes Objekt erstellst, sondern im "Draw Event" des Spielers malst. dazu musst du draw_self() hinzufügen da sonst dein Spieler nicht mehr gemalt wird, sofern du dies noch nicht zuvor rausgefunden hast. Um die Animation zui positionieren würde ich mit den lengthdir funktionen arbeiten (lengthdir_x(),lengthdir_y()). Dann malst du an x + lenx und y + leny. hoffe das hilft als erster Anreiz