Suchergebnisse

Das ginge auch, aber wenn du große Maps hast könnte der Grafikspeicher schnell überlaufen. Wobei du auch eine Surface die nur ein Viertel oder ein Achtel der Auflösung der Map hat nutzen könntest. Indem Fall brauchst du nur eine komplett schwarze Surface und radierst mittels Blendmode den Bereich um deine Einheiten aus.

Spontan fallen mir da zwei Möglichkeiten ein: Objekte flächendeckend im room platzieren, welche bei Berührung mit Player/Einheiten sich selbst destroyen oder mit einem Grid arbeiten. Bei beidem wäre es das einfachste mit (größeren) Quadraten zu arbeiten, das man also immer eckige Segmente aufdeckt. Etwas mehr Aufwand wären rundungen, würde dann auf eine Art Autotiling hinauslaufen. Wenn du kein eigenes System programmieren willst kannst du auch mal nach "Fog of War" googlen. Findet sich bestimmt…

mit dem zweiten Code überschreibst du deine globale Variable, sodass am ende nur die letzte ID abgefragt wird und alle davor ignoriert werden. Könntest das mit einem Array machen, also controller[i] statt controller.

Klingt so als würdest du das Draw GUI-Event statt dem normalen Draw-Event für die Sprites nutzen. Man kann allerdings auch die Auflösung der GUI-Surface manuell festlegen, sodass es auf allen Bildschirmen und AUflösungen am Ende gleich aussieht.

Soweit ich mitbekommen habe übersetzt GM Studio 2 die alten nicht mehr unterstützten Befehle in neue wie zb. instance_create(), sodass man nur bei besonderen Spielen, welche auf Extensions oder DLLs zurückgegriffen haben evtl. Hand anlegen muss um sie wieder zum Laufen zu bekommen. Selbst ausprobiert hab ich es aber noch nicht, nur posities Feedback im YoYo FOrum gelesen, wie unkompliziert das importieren alter Projekte klappt.

Ja genau daran liegt es. Wenn du Up gedrückt hältst, dann hast du einen Vorwärtsschub in Blickrichtung.

Sonst haste nichts zusätzliches? Irgendwo noch ein D&D Action oder ähnliches? Sieht nämlich richtig aus und beim drehen sollte sich die Bewegungsrichtung nicht ändern.

Klingt so als hättest du irgendwo image_angle und direction vertauscht. Am besten kopierst du deinen Code hier rein, damit wir den Fehler identifizieren können. Das Tutorial selbst macht alles richtig auf den ersten Blick.

Bin mir grad nicht 100% sicher, aber speichert GM die Subimages eines Sprites nicht bereits in Einzelbilder ab? Schau mal in dein Projektordner.

Ohne deinen Code oder Room zu sehen können wir schlecht weiter helfen. Entweder ist im Code selbst eine Sperre drinnen oder es ist doch etwas im Room platziert. Manchmal passiert es, dass man beim rescalen eines Objektes im Room es auf einer Achse auf 0 scaled. Vielleicht ist dir das passiert.

Dann liegt dort wohl irgenwo der Fehler begraben. Kannst ja mal den "gravity" Wert vom Gegner neben ihm drawen lassen um zu kontrollieren, dass er wirklich >0 ist während er "fliegt". Btw. gravity_direction muss dann natürlich 270 sein, sonst beschleunigt er nach rechts

Wenn du "room_speed/room_speed" nutzt kannst du das gleich durch "1" ersetzen

Mein Code bewirkt aber, dass er sich bewegt und entsprechend hspeed und vspeed werte hat. Daher musst du sie bei Kollision mit dem Boden wieder auf 0 setzen. Dann bleibt er auch stehen.

Dann hat der Gegner entweder keine gravitation gesetzt oder hspeed und vspeed wird nicht wieder auf 0 gesetzt, wenn er auf dem Boden landet.

Ne, instance_place gibt die id der instanz zurück, da du sie aber gar nicht aufgreifst, wäre place_meeting performanter. Wenn er nicht hoch genug springt ist entweder jspd zu klein oder die gravitation zu hoch.

Zum Beispiel so: Kollisionsevent von Explosion mit Gegner: GML-Quellcode (6 Zeilen) Das sorgt schonmal dafür, dass der Gegner von der Explosion nach rechts/links weg geschleudert wird, je nachdem auf welcher Seite der Gegner steht. Im Gegner Objekt müsstest du jetzt ähnlich wie beim Player Objekt dafür sorgen, dass gravity wirkt wenn kein Boden unter den Füßen ist und bei Kollision mit dem Boden hspeed und vspeed wieder auf 0 setzen.

Du könntest das umgehen, indem du im Kollisionsevent den schaden austeilst und eine Variable auf 1 setzt und im EndStep-Event abfragst ob die Variable 1 ist und dann zerstörst. Dadurch sollten alle Kollisionsevents triggern bevor das Objekt zerstört wird.

GML-Quellcode (4 Zeilen) Davon abgesehen, wäre place_meeting() nicht die bessere Funktion in dem Fall, da du sowieso nicht mit einem Rückgabewert arbeitest? Denke mal dass es ein wenig Performance spart.

Ich merke grad, dass du geschweifte Klammern falsch gesetzt hast, so sollte das gehen: GML-Quellcode (23 Zeilen)

Wäre ja Blödsinn wenn der eigene Schwertschlag einem schaden zufügen kann. Von daher kann das Schadensobjekt so lange existieren, wie die Schwertschlag Animation abgespielt wird oder bis ein Gegner getroffen wird.