Ergebnis 1 bis 3 von 3

Thema: Problem mit sich überschneidenden MoveEvent-Befehlen

  1. #1

    Problem mit sich überschneidenden MoveEvent-Befehlen

    Tach alle zusammen!

    Ich bastel derzeit an einem AKS und habe das Problem, das Animationen (Treffer, Angreifen, Springen etc.) über das CharSet des Helden und einem dazu gehörenden "MoveEvent"-Befehl verarbeitet werden.

    Nun gibt es aber ein Problem bei der Sache:
    Nehmen wir als Beispiel, der Spieler drückt eine Taste um zwischen Rennen und Gehen umzuschalten. Mehr oder minder zeitgleich oder mit einer kleinen Verzögerung drückt er die Taste zum springen. Sofern der MoveSpeedUp oder MoveSpeedDown Befehl zum Wechsel von Rennen/Gehen noch nicht ausgeführt wurde, kann es vorkommen das er durch das MoveEvent zum Springen abgebrochen wird, und der Held sich dementsprechend einen MoveSpeedUp schneller oder einen MoveSpeedDown langsamer bewegt. Das passiert zwar eigentlich nur wenn man die Tasten schnell hintereinander drückt, aber im Hinblick auf eventuelle Treffer, Strafe-Animation etc. wo es zu noch mehr solcher "überschneidungen" kommen kann wird das noch problematischer.

    Für den Anfang habe ich es jetzt so gelöst, das wenn eine Animation anfängt ein Switch auf on gestellt wird, der verhindert das zeitgleich ein anderes MoveEvent auf den Helden angewendet werden kann. Bei Tastenabfragen geht das noch aber später bei Treffer&Angriff (ist nicht mein erstes AKS) kann das dazu führen das das Spiel zwischendurch kurz "stehen" bleibt oder eine Animation komplett ausbleibt.

    Meine Frage an euch wäre nun ob ihr eine Möglichkeit wüsstet wie man solche Überschneidungen besser ausbügeln bzw. verhindern kann als mit einem Switch.

  2. #2
    Hmm... schwer das so abstrakt abzuhandeln.
    Ich hab bei meinem Spiel ein ähnliches Problem. Allerdings geht es dort nicht um sichtbare Aktionen sondern Einstellungen im Hintergrund. Daher weiß ich nicht, ob meine Idee bei deinem KS funktioniert.
    Statt ein Event direkt aufzurufen, habe ich einen Switch eingegebaut, dessen Aktivierung die Startbedingung für einen parallel process ist. Allerdings nicht in Form einer Fork sondern als Wartebedingung für das Event. Sozusagen ein Ampelsystem im Straßenverkehr. Bei roter Ampel (Switch on) wird gewartet bis er of ist.
    Der Unterschied zu deinem Switch ist, dass jedes Event auf jeden Fall drankommt, da es für jedes Event einen eigenen Switch gibt. Dieser geht erst aus, wenn genau dieses Event ausgeführt wurde.
    Ich weiß nicht, inwiefern du das schon benutzt hast. So wäre zumindest das Überspringen von Animationen verhindert. Nur wird es vielleicht zu Verschiebungen kommen.

  3. #3
    Hmm... daraus könnte man theoretisch eine Art "MoveEVent Warteschleife" machen.

    Verzögerungen oder verschiebungen sind vorrauszusehen, aber ich kann diese Möglichkeit jedenfalls dafür verwenden das die wichtigsten Befehle wie "MoveSpeedUp" etc. auf jeden Fall ausgeführt werden. Ob ne Animation unterbrochen wird ist fast noch egal. Bzw. das passt mir ganz gut da so der Held auch während eines Angriff getroffen werden kann. Dann muss ich zwar die MoveEVentBefehle splitten, aber immer noch besser als wenn der Held auf einmal einen auf Speedy Gonzales macht....

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •