Jetzt bin ich erst recht verwirrt. Wenn es sein kann, dass beim Spiegelbild ein Hindernis ist und bei der Spielfigur nicht, dann passt sein ganzer Code nicht, weil dieser Umstand nicht berücksichtigt wird.
Jetzt bin ich erst recht verwirrt. Wenn es sein kann, dass beim Spiegelbild ein Hindernis ist und bei der Spielfigur nicht, dann passt sein ganzer Code nicht, weil dieser Umstand nicht berücksichtigt wird.
Danke für die ganzen Antworten und Ideen.
Also worauf das ganze hinauslaufen soll ist, dass ich versuche, mit Events ein kleines Interface auf der Map darzustellen. Ich würde das ja mit Pictures machen aber die sind begrenzt und mit dem Resource Hacker bin ich leider zu ungeschickt und auch nicht wirklich fähig, die Anzahl der Bilder in die Höhe zu schrauben.
Das Interface soll sich halt genau mit dem Helden mitbewegen, damit das quasi so eine Art "Rahmen" am unteren Bildschirmrand zieht.
@ Alle: Das Problem ist teilweise genau umgekehrt. Der Spieler läuft gegen eine Wand. Das bedeutet für das System, dass ich afaik ein Move Event in die Richtung ausgelöst habe. Das wiederum führt dazu, dass sich das Spiegelbild bewegt (es bekommt ja das Signal durch das Move Event), obwohl der Spieler aber durch ein Hindernis die Bewegung tatsächlich gar nicht ausführen kann. Deswegen ist der Fall auch egal, ob das Spiegelbild irgendwo hängenbleibt, das wird später sowieso auf Phasing Mode ON und Above Hero Layer gesetzt. Es geht wirklich nur darum, dass sich das Spiegelbild oder besser dann das Interface später nicht bewegen darf, wenn ich als Spieler an einem Hindernis stehe und versuche, quasi in das HIndernis zu laufen. Ob beim Spiegelbild ein Hindernis ist oder nicht, ist erst einmal völlig irrelevant ^^.
@Leana: Die Ausführung der Bewegung ist ja von 2 Sachen abhängig. Einmal, welche Taste ich gedrückt habe, damit auch die richtige Bewegung ausgeführt wird und dann wiederum, ob sich beim Spieler ein Hindernis befindet und er die Bewegung quasi gar nicht richtig ausführen kann. Deshalb habe ich das auch so geschachtelt gemacht, weil ich genau genommen gar nicht vorher weiß, ob sich an besagter Stelle gerade ein Hindernis befindet oder nicht.
Und mit "Proceed with Movement" ergibt sich leider das Problem (so wie es noch derzeit ist), dass das nur funktioniert, wenn die beiden Move Events zeitgleich starten. Und wegen dem Herumgerechne oder den Waits, gelingt das leider irgendwie nicht :S
@ Eddy131: Das mit dem Charakter verstehe ich leider gar nicht ^^ Dann ist die Figur aber dennoch ein Event oder? Würden sich daraus aber nicht die gleichen Probleme wie jetzt ergeben?
@ BDraw: Ich habe auch die Vermutung das es an den 0.1 Waits liegt aber 0.0 Waits bringen ja leider auch keine Besserung. Im Gegenteil, da kommt der Code einfach nicht hinterher, weswegen 0.1s quasi schon das Minimum darstellt.
Der Gedanke mit der Terrain - ID kam mir auch, aber da weiß ich auch nicht genau, ob ich am Ende dann nicht wieder dabei lande, das sich das System dann quasi aufhängt oder einfach nicht hinterher kommt.
Nochmal Danke für die Hilfen und Ideen ^^
Edit: Also unter Nutzung von Terrain - IDs klappt das mit der Geschwindigkeit einwandfrei. Danke dafür nochmal an BDraw.
Jedoch bewegt sich mein Held und das Spiegelbild immer 2 Felder in die jeweilige Richtung und ich leider keine schlüssige Idee habe. Also vielleicht, weil sich der Spieler mit der Tasteneingabe ja von Hause aus in die Richtung bewegt. Dann müsste das aber theoretisch nur bei links und rechts passieren. Die Figuren laufen aber auch immer 2 Felder wenn man nach oben-rechts bzw. unten-links läuft. Die Kollision will mir aber auch mit den Terrain - IDs nicht gelingen.
MfG Draegor
Geändert von Draegor (22.03.2016 um 22:38 Uhr)
Da du ja erst nach dem Move-Event der Spielfigur weißt, ob diese sich bewegt hat oder nicht, geht es nicht ohne kleine Verzögerung. Ich würde alles in einen CE packen, weil man sich dadurch schon mal unnötige Abfragen spart (z.B. die Abfrage im anderen CE, welche Taste gedrückt wurde) und die kosten ja auch Zeit. Und die Prüfung, ob die Spielfigur sich bewegt hat, würde ich nach dem Speichern der aktuellen Position durchführen. Falls aktuelle Position != alter Position, dann Spiegelbild nachführen, ansonsten passiert nichts. Ich denke, die Verzögerung ist auf diese Weise so gering, dass man sie (fast) nicht bemerkt.
Also, wie ich das jetzt verstanden habe: Du willst am unteren Bildschirmrand quasi eine Grafik einblenden die Permanent (vom Bildschirm, nicht der Map, aus gesehen) auf der gleichen Stelle steht.
Dafür möchtest du aber nicht die Makereigene Grafikanzeige nutzen, weil die irgendwie beschränkt ist und du die Anzahl der Möglichen Objekte schon ausgereizt hast.
Soweit stimmig?
Was ich meinte ist, dass du die Grafik deines Helden mit dem erweiterst, was du anzeigen lassen möchtest.
Der Held kann ja unendlich groß oder klein werden.
Nimm dann einfach eine Grafik, die Bildschirmfüllend ist, setze den Helden wie gewohnt in die Mitte und dein Interface dahin, wo es sein soll und den Rest lass transparent.
Wenn sich das Interface ändert (ich weiß ja nicht, was genau du da anzeigen lassen möchtest), dann änderst du einfach die Grafik des Helden zu einer, wo das angepasste Interface angezeigt ist.
Du müsstest nur darauf achten, dass der Held sich immer exakt in der Mitte des Bildschirms befindet, sonst läuft dein Interface mit.
Also Karten immer so groß machen, das man mit der Figur - und damit mit dem Bildschirm - nicht an den Rand der Maps kommt.
Ob das die Performanteste, einfachste oder sonstwie beste Methode ist, weiß ich nicht.
Sie müsste aber funktionieren, wenn du dich an die Einschränkungen hältst.
Mit Grafiken arbeiten wäre hier meine erste Wahl, aber das geht bei dir ja scheinbar nicht.
So, ich hoffe das war jetzt verständlicher und hat dir geholfen
Kurze Randinfo: Nein, kann er nicht, das geht erst ab dem XP aufwärts. Der 2k/3 hat für jedes Charset eine fixe Größe von 24x32px. Alles darüber benötigt mehrere Charsets, die aber Synchron zu bewegen führt zu exakt dem Problem, was Draegor ja eh schon hat.Zitat von Eddy131
@Draegor:
Wie Leana schon richtig angemerkt hat: Eine minimale Verzögerung gibt es so oder so, wenn du abfragst, ob der Held sich bewegt hat. Das präziseste wäre da die Pixelkoordinaten abzufragen, was aber Feintuning braucht, damit die Abfrage nicht zu schnell wird (und eben genau darin mündet, dass das Event sich zu weit bewegt). Die einzige komplett, 100% synchrone Variante wäre das direkt in die Heldensteuerung zu integrieren, was aber eben eine Kollisionsabfrage voraussetzt. Bzgl. der Performance: Reine Rechenoperationen bekommt der Maker eigentlich sehr schnell hin, von der Seite aus gäbe es kein Problem. Schwierig wird es immer dann, wenn du auf einmal viele parallele Prozesse gleichzeitig laufen hast (die evtl. auch noch ineinandergreifen) oder wenn da waits drin sind, da damit merkliche Pausen entstehen. Ein wait mit 0.0 merkt man eigentlich nicht, 2x0.0 kann schon dazu führen, dass man als Spieler was mitbekommt, wenn davon Bewegungen abhängen. (0.0 "Maker-Sekunden" = 1/6*0.1s = 1/60s, 2x0.0 = 1/30s. Afaik kann das Auge etwa 1/60s wahrnehmen?)
Von proceed with movement würde ich auf alle Fälle die Finger lassen - zum Einen sorgt der Befehl nicht dafür, dass dinge sich gleich schnell oder gleichzeitig bewegen, er hält bloß alles an, bis alle aktuellen move events fertig ausgeführt wurden. Zum Anderen kann eben das dazu führen, dass, im Falle eines Hinterherhinkens des Spiegelbilds, der Code blockiert wird, der den Helden bewegt, was sich aus Spielersicht darin äußert, dass man scheinbar relativ zufällig die Figur manchmal (oft) nicht bewegen kann.
Aber ganz ehrlich, bei dem Aufwand würde ich an deiner Stelle echt überlegen, Pictures zu nehmen. Der Aufwand steht sonst echt in keinem Verhältnis, gerade für sowas wie ein Interface. Schau mal wenn der Maker wieder bei Steam im Angebot ist, die Version hat inzwischen deutlich mehr als die 20 Pictures die es früher nur gab. Und wenn du nicht gerade ein komplett Picture-basiertes Menü mit drölfzig Ziffern hast kommst du mit 50 Pics normalerweise auch gut aus, wenn du etwas haushaltest.
Dazu kommt vor allem dass, wenn ich dich richtig verstehe von wegen "Rahmen" und so, es gar nicht um die Bewegung des Helden geht, sondern um die der Kamera - und die kann man nicht ohne weiteres abfragen. Am Maprand würdest du also in noch mehr Probleme laufen, sofern du nicht dann ein eigenes Scrollingsystem einbaust oder konstant auch noch Map- mit Screenkoordinaten vergleichst. Wenn du aber einfach ein Picture nehmen könntest und gut ist würde ich mir den Aufwand schenken.
Geändert von BDraw (23.03.2016 um 00:41 Uhr)
Oh, danke für die Info.
Das wusste ich tatsächlich nicht, dachte dass mit den Variablen größen gab es schon vorher, immerhin gibt es ja auch bei den Spielen mit den 2k/3 Makern größere Gegner-Grafiken auf der Map (?), daher ging ich davon aus, dass das auch für den Helden gelten müsste.
Ganz meine Rede
Ne, das ist bei allen Charsets der Fall. Man kann theoretisch natürlich größere Sachen aus mehreren Charsets zusammenstückeln - ob das jetzt ein Gegner, ein Baum oder ein Haus ist, ist ja egal - somit wie sich beide Events synchron frei (d.h. bspw. außerhalb einer Cutscene, wo die Bewegungen ja 100% vorgegeben sind) bewegen sollen wird es bloß immer etwas knifflig.
Charsets sind immer exakt gleich aufgebaut: ein Char hat 24x32px, ein Charset für einen Char hat damit immer 72x128px (3 Frames * 4 Richtungen) und ein ganzes Charset wie man es importiert (für insg. 8 Charaktere; 4 oben, 4 unten) 288x256px. Alles darunter nimmt der Maker gar nicht erst an. Die wiederum werden für Helden, Map-Events und Vehicles gleichermaßen verwendet.
Geändert von BDraw (23.03.2016 um 11:23 Uhr)
Inwiefern ist der Aufwand geringer, wenn er anstatt eines Events ein Picture benutzt? Ob man ein Event nachführt oder ein Picture, ist doch vom Ablauf das Gleiche? Und das Problem mit dem Maprand hat er doch immer. Schließlich soll diese Anzeige bestimmt auch weiterhin sichtbar sein, wenn die Spielfigur dort entlang läuft.
So wie ich es verstanden habe, versucht Draegor, einfach ein Interface (/Rahmen/Menüteil/...) irgendwo anzuzeigen, welches sich natürlich mit dem Bildausschnitt mitbewegen soll. Das ist aber genau das, was ein Picture von Haus aus tut, ganz ohne Abfragen, etc., sofern man nicht "Scroll with Map" anklickt. Das Picture hat seinen Platz dann fest auf der Kamera sozusagen und ist von der Map bzw. was der Char auf dieser treibt völlig losgelöst. Um den selben Effekt, der in jedem Show Picture-Befehl von vorn herein drin ist, aber mit Charsets hinzubekommen, muss man es manuell passend zur Kamera bewegen, was ein relativ großer Aufwand ist.
EDIT: gerade nochmal geschaut, der legale 2k3 unterstützt bis zu 1000 Pictures und kostet momentan 19,99€.
Geändert von BDraw (23.03.2016 um 12:04 Uhr)
Aber Draegor spricht doch die ganze Zeit davon, dass das Interface dem Helden folgen soll und nicht, dass es "fest" an einer Stelle bleiben soll. Ich denke, das mit dem "Rahmen" ist eher so gemeint, dass sich das Interface halt immer am unteren Bildschirm hin- und herbewegen soll. Denn der Held macht ja auch stets eine Bewegung in der X-Richtung, auch wenn die Auf.- bzw. Ab-Taste gedrückt wurde.
Läuft doch aufs selbe hinaus. Wenn der Held sich bewegt nimmst du das bei einer größeren Map ja eigentlich dadurch war, dass sich die Map bewegt, bzw. scrollt. Der Held bleibt ja in der Mitte des Bildausschnitts fest. Das ändert sich nur, wenn der Held an den Rand der Map kommt, da die Kamera da eben nicht weiter kann.
Optisch ist es also in der Mitte der Map total egal ob das Interface dem Helden "folgt" oder als Picture quasi am Bildausschnitt befestigt wird. Erst am Maprand macht sich der Unterschied bemerkbar und auch das ist das mit Pictures kein Problem, da man problemlos einstellen kann, dass das Picture immer die X-Koordinate der Pixelposition des Helden haben soll. Fertig.
"Fest" im Bezug auf Charsets ("fest auf der Map") würde ja bedeuten, dass das Event aus dem Bildausschnitt verschwindet, wenn der Held sich wegbewegt. "Fest" im Bezug auf Pictures bedeutet aber (normalerweise) fix auf dem Bildausschnitt, nicht auf der Map.
Aber ehe wir weiter darüber diskutieren, was genau Draegor jetzt eigentlich vorhat, wäre es wohl einfacher, wenn er einfach erklärt, was genau er denn jetzt umsetzen will (idealerweise mit einem Bild oder so), dann kann man auch a) sagen, was jetzt eine geeignete alternative Lösung wäre und b) beurteilen, wie komplex das überhaupt tatsächlich sein muss.
Geändert von BDraw (23.03.2016 um 14:01 Uhr)
Der Meinung bin ich btw. auch.
Das Interface sieht wie folgt aus und ist starr am unteren Bildschirmende verankert:
In Bildern wäre das wie folgt:
12 Bilder benötige ich für die HP Zahlen und dann noch einmal 12 für die MP Zahlen, habe ich von 50 nur noch 26 übrig. Dann brauche ich noch mal 3 Namen (bleiben 23), jeweils 3 Leisten für jeweils 3 Charaktere, also noch einmal 9 Bilder (bleiben noch 14). Die grüne Leiste wird noch einmal mit einer Roten unterlegt, sind dann noch 11 verbleibende Bilder. Dann noch einmal 3 Bilder für die Aktionswert - Zahlen für noch einmal 3 Charaktere. Somit noch einmal 9 Bilder. Bleiben am Ende "nur" noch 2 übrig. Dann noch einmal den Rahmen samt Hintergrund und ich habe nur noch ein Bild, was ich dann eventuell für Gegner, Einblendung, Lichteffekt oder ähnliches verwenden kann.
Nochmal zusammengefasst:
50 Maker - Bilder
- 4 x 3 Bilder für HP Zahlen
- 4 x 3 Bilder für MP Zahlen
- 3 x 1 Bild für Namen
- 3 x 1 Bild für HP - Leiste grün
- 3 x 1 Bild für HP - Leiste rot (grau ist hier integriert)
- 3 x 1 Bild für Limit - Leiste (orange)
- 3 x 1 Bild für AP - Leiste (gelb, rot, grau)
- 3 x 3 Bilder für AP Zahlen
- 1 x 1 Bild für den Hintergrund.
Macht insgesamt: 50 - 12 - 12 - 3 - 3 - 3 - 3 - 3 - 9 - 1 = 49 ==> also nur noch 1 Bild! für andere Nutzung übrig.
Und genau deswegen versuche ich das quasi über Events zu lösen.
Mir ist durchaus bewusst, dass sich das mit Pictures viel einfacher lösen lässt. Man könnte ja auch eine Kompromisslösung aus Charset und Pictures nutzen. Aber selbst dann bräuchte ich quasi die Kollisionsabfrage, damit das Interface auch wirklich am unteren Bildschirmrand läuft und bleibt und nicht auf einmal beispielsweise in einer der Ecken hängt oder in der Mitte der Map. Abspecken wollte ich das Interface wirklich ungerne.
Das Problem mit dem Geschwindigkeitsverlust hat sich ja mittlerweile bereinigt durch BDraws Idee mit den Terrain - IDs.
Aber ich bin selber irgendwie zu dumm, die hauseigene Bewegung des Spielers zu unterdrücken und dann die Move Events so zu erstellen, dass sich das Interface nur dann bewegt, wenn sich auch die Position des Spielers verändert.
Dabei ist die Mapgröße bzw. der Fakt, dass man theoretisch an den Rand der Map gelangen könnte egal. Die Maps werden dann so beschaffen sein, dass es für den Spieler nicht möglich ist, sich bis an den Kartenrand zu bewegen. Ich simuliere ihm vielleicht einen aber erreichen wird er ihn nie.
Sry wenn das alles etwas verwirrend ist. Ich würde im Zweifelsfall auch das Projekt hochladen, wenn das vielleicht zum besseren Verständnis beiträgt.
MfG Draegor
Wie gesagt, nimm den legalen 2k3 und du hast das Problem nicht. ._. Mit den 50 Pictures des "alten" 2k3 ist das mit Pictures tatsächlich blöd; entweder du hast hinterher nur noch 1 Bild übrig, oder du müsstest bspw. die Zahlen zusammenfassen (also anstatt nur Bilder von 0-9 von 0-99, was aber natürlich viel mehr Arbeit beim Erstellen der Grafiken ist und unterm Strich auch vglw. wenig einspart).
Pass bloß auf wenn du es tatsächlich mit Events machst, dass sich dein Interface nicht mit anderen Events in die Haare kommt. zwei Events die beide auf der selben Ebene sind (bspw. above hero) fangen sehr gerne an grafisch rumzuzicken, welches jetzt oben und welches unten ist. Kann blöd werden wenn du bspw. irgendwo ein Stück Baumkrone als Event darstellst - außer natürlich, du machst einen Sidescroller.
Wenn du die hauseigene Bewegung unterdrücken willst wäre das einfachste, wenn du deine Bewegungssteuerung als AutoStart-Event machst. Dann kann der Spieler sich nicht mehr über das 0815-System bewegen. Alternativ könntest du natürlich den Helden ganz transparent stellen, die Kamera auf fixed stellen und ein Event als Heldenchar nehmen und steuern, müsstest dann aber die Kamera auch manuell steuern.
Berechtigungen
Zitieren
