Hilfe zum Maniacweed-Starterpak

[AmigaMaster]

Weiß jemand, warum man die ganzen Wait() vor unzähligen Aktionen gemacht hat, auch bei den Dialogen? Die Verzögern doch nur minimal (125ms) die nächste Aktion und eigentlich braucht man sie die meiste Zeit doch nicht, außer man will bewusst eine Verzögerung haben. Oder hat das andere Hintergründe, weil dann etwas anderes nicht funktioniert hat?

Zum Beispiel hier ein Auszug aus Bernards Raum:

Code Auswählen Erweitern

function hCertificate_AnyClick()
{
  if (Verbs.AnyClickMove(175, 120, eDirectionUp))
  {
    if (Verbs.UsedAction(eGA_WalkTo))
    {
      // Wait(5);
    }
    else if (Verbs.UsedAction(eGA_LookAt))
    {
      Wait(5);
      player.Say("'Gewinner des Eierkopfpreises.'");
    }
    else if (Verbs.UsedAction(eGA_PickUp))
    {
      Wait(5);
      player.Say("Ich lass es, wo es ist.");
    }
    else if (Verbs.UsedAction(eGA_Use))
    {
      Wait(5);
      player.Say("Ich will es nicht beschädigen.");
    }
    else if (Verbs.UsedAction(eGA_Open))
    {
      Wait(5);
      player.Say("Ich kann es nicht öffnen.");
    }
    else if (Verbs.UsedAction(eGA_Close))
    {
      Wait(5);
      player.Say("Ich kann es nicht schließen.");
    }
    else if (Verbs.UsedAction(eGA_Pull))
    {
      Wait(5);
      player.Say("Ich lass es, wo es ist.");
    }

[Bòógieman]

Vermutlich als Stilmittel. Weil eine sofortige Reaktion nach dem Klick irgendwie überfordernd ist, wenn das wie aus der Pistole geschossen kommt. Eine minimale Verzögerung gibt dem Spieler da kurz Zeit um sich auf die Reaktion zu konzentrieren. 
Bzw. ist es auch schöner, wenn die Spielfigur das Objekt ansieht und erst dann zu reden beginnt, als wenn direkt bei der Drehung schon gesprochen wird.

[1mal_volltanken]

Weiß jemand, warum man die ganzen Wait() vor unzähligen Aktionen gemacht hat, auch bei den Dialogen? Die Verzögern doch nur minimal (125ms) die nächste Aktion und eigentlich braucht man sie die meiste Zeit doch nicht, außer man will bewusst eine Verzögerung haben. Oder hat das andere Hintergründe, weil dann etwas anderes nicht funktioniert hat?

Zum Beispiel hier ein Auszug aus Bernards Raum:

Code Auswählen Erweitern

function hCertificate_AnyClick()
{
  if (Verbs.AnyClickMove(175, 120, eDirectionUp))
  {
    if (Verbs.UsedAction(eGA_WalkTo))
    {
      // Wait(5);
    }
    else if (Verbs.UsedAction(eGA_LookAt))
    {
      Wait(5);
      player.Say("'Gewinner des Eierkopfpreises.'");
    }
    else if (Verbs.UsedAction(eGA_PickUp))
    {
      Wait(5);
      player.Say("Ich lass es, wo es ist.");
    }
    else if (Verbs.UsedAction(eGA_Use))
    {
      Wait(5);
      player.Say("Ich will es nicht beschädigen.");
    }
    else if (Verbs.UsedAction(eGA_Open))
    {
      Wait(5);
      player.Say("Ich kann es nicht öffnen.");
    }
    else if (Verbs.UsedAction(eGA_Close))
    {
      Wait(5);
      player.Say("Ich kann es nicht schließen.");
    }
    else if (Verbs.UsedAction(eGA_Pull))
    {
      Wait(5);
      player.Say("Ich lass es, wo es ist.");
    }

Die Entwickler von einst Lucasfilm Games hatten für das Wait-Event auch eine "Schnecke" als Cursor eingebettet.

Für Wait kann man in AGS sogar einen anderen Cursor dort hinterlegen. (Beispielsweise die Schnecke)

Dann hätten diese Wait-Zeilen auch den Zweck, dass für einen kurzen Augenblick die Schnecke auftaucht.


Edit: Hab mir das Maniacweed-Bernard-Starterpak runtergeladen. Das Scrolling sieht jetzt richtig flüssig aus.



BG
der Volltanker

[alphawolf300]

Super, dass ihr das Starterpack erweitert!

Wie wäre es denn mit einem Thread, in dem jeder Zugang zu einem MMM-Projekt, basierend auf dem Tumbleweed-Starterpack hat, und jeder kann irgendwas für eine Episode einbauen, was ihm gerade in den Sinn kommt. Gegenstände, Kommentare, Dialoge, Rätsel, irgendwas. Irgendwann muss man dann alle Fäden irgendwie zusammenspinnen und hat eine Gemeinschaftsepisode.

[AmigaMaster]

Edit: Hab mir das Maniacweed-Bernard-Starterpak runtergeladen. Das Scrolling sieht jetzt richtig flüssig aus.

Ich habe AGS auf 60 FPS gestellt. Was das im Einzelnen bedeutet (zumindest das, was ich mir erarbeiten konnte basierend auf Doku's):

• Alle statischen Wait() Werte durch eine Berechnung basierend auf dem GameSpeed() angepasst. Damit sind diese unabhängig von der Framerate (ca. 1000 Zeilen in den Quelltexten)
• Alle Animation Delays für Objekte und Charaktere angepasst, damit die bestehenden Animationen nicht 50% schneller laufen
• .Animate Delay (z. B. für die Telefon Klingelanimation) angepasst
• Movement Speed aller Charaktere angepasst

Eine Auswirkung davon ist, dass der Credits-Scroller, da er bereits pro Frame nur 1 Pixel scrollt, jetzt 50% schneller scrollt. Man könnte das noch mit einem Delay von 1 Frame verzögern aber dann hätte man 30 FPS anstatt vorher 40 FPS.

Fällt jemandem von Euch noch etwas ein, was jetzt schneller laufen könnte?

[1mal_volltanken]

Ja, sicher kann man da noch justieren. Ich wüsste jetzt bspw. nicht, welche Auswirkungen es auf Timer-Funktionen haben könnte, falls jemand auch Timer mit einbauen möchte.

Was mir noch einfällt:

Bei damaligen Starterpaks gabs ja noch diese Problematik, dass die "Give to Charakter"-Funktion nur in Kombination mit "Use with Charakter" funktionierte. Ist das beim Maniacweed-Starterpak eigentlich immer noch so oder funktioniert "Give to" jetzt auch unabhängig?


BG
der Volltanker

[AmigaMaster]

Ja, Timerfunktionen laufen dann auch mit 60 Ticks pro Sekunde. Meine Frage zielte auch eher auf das Starterpack ab, da ich dort keine Timer gefunden hatte (SetTimer / IsTimerExpired).

Generell hilft bei allem, was mit den Ticks arbeitet die GetGameSpeed() Funktion:
Diese liefert die eingestellte Engine-Geschwindigkeit zurück, also bei 60 FPS 60 (das entpricht den Ticks) und das entspricht dann einer Sekunde (sofern AGS die Framerate halten kann, ansonsten verlängert sich diese Sekunde in der Echtzeit).
Jetzt kann man diesen Wert einfach multiplizieren (für mehr als 1 Sekunde) oder dividieren (für den Bruchteil einer Sekunde) und der Wert ist immer passend zur Framerate des Spiels.

Nach Tests funktioniert wait() damit auch mit Float-Werten, da wait() vermutlich einfach die Nachkommastellen ignoriert. Damit konnte ich auch die Achtelsekunden aus der 40FPS-Version (=5 Ticks) einfach in die 60 FPS-Version übernehmen (=7,5 Ticks). Ansonsten gibt es aber bestimmt auch eine Round()-Funktion in AGS, die auf Integer runden kann.

P.S:
Braucht jemand eine animierte (ein- und ausgeblendete) Hotspots? Zuerst dachte ich, es wäre eine gute Idee, als ich es dann im Spiel gesehen habe, gefiel es mir aber nicht wirklich. Ich habe es aber so implementieren können, dass man es faktisch auch ausschalten kann, indem man  _max_transparency auf 0 setzt.

Code Auswählen Erweitern

ShowHotspots3.1.asc
@@ -19,6 +19,16 @@ int g=70, b=70;
 int islot=-1;                    // default icon: drawn circle
 int ox, oy;
 
+// Fade effect
+// Initial start values
+int _fade_alpha = 0;
+int _fade_step = 1;              // Transparency direction (1 = fade-out, -1 = fade-out)
+int _fade_timer = 0;
+
+// Fade settings
+int _max_transparency = 30;      // 100 = fully transparent,  0 = not transparent
+int _fade_delay = 1;              // Slow down effect by a delay: 1 = default speed, 2 = every second frame,  3 = every third frame,  etc.
+
 static function ShowHotspots::SetKey(eKeyCode keycode) {
  _showhotspots_key = keycode;
 }

@@ -204,11 +214,17 @@ function _Prepare() {
  normalfont = Game.NormalFont;
  Game.NormalFont = _showhotspots_font;
 
+  // Reset start values for transparency and timer
+  _fade_alpha = 0;
+  _fade_step = 1;
+  _fade_timer = 0;
+
  // Create screen sized transparent sprite
  hotspotSprite = DynamicSprite.Create(Screen.Width, Screen.Height, true);
 
  // Create overlay
  hotspotOverlay = Overlay.CreateGraphical(0, 0, hotspotSprite.Graphic, true);
+  hotspotOverlay.Transparency = _fade_alpha;
 
  // Search and update hotspot condition
  _SearchHotspots();

@@ -241,6 +257,28 @@ function repeatedly_execute_always() {
      _Prepare();
    }
   
+    // Start fade-in and fade-out
+    _fade_timer++;
+    if (_fade_timer >= _fade_delay) {
+      _fade_timer = 0;
+     
+      _fade_alpha += _fade_step;
+     
+      if (_fade_alpha >= _max_transparency) {     
+        _fade_alpha = _max_transparency;
+        _fade_step = -1;      // Switch to fade-in
+      }
+      else if (_fade_alpha <= 0) { 
+        _fade_alpha = 0;
+        _fade_step = 1;        // Switch to fade-out
+      }
+     
+      if (hotspotOverlay != null && hotspotOverlay.Valid) {
+        hotspotOverlay.Transparency = _fade_alpha;
+      }
+    }
+    // ---------------------------------------------------
+
    // Redraw Overlay for each frame
    drs = hotspotSprite.GetDrawingSurface();
    drs.Clear(COLOR_TRANSPARENT);

Das sieht dann mit _max_transparency = 30 und _fade_delay = 1 so aus:
Sie dürfen diesen Dateianhang nicht ansehen.

[1mal_volltanken]

Hallo AmigaMaster!

Mit welcher Taste aktivierst Du denn die HotSpot-Anzeige?

Ich werde diese Funktion wahrscheinlich nicht mehr in mein Projekt implementieren, aber wer weiß?! - Vielleicht gibt es ja Entwickler, die dieses Feature behalten wollen. Kenne diese Hotspot-Anzeige vor allem auch nur aus Baphomets Fluch. Die LucasArts-Spiele hatten diese Funktion glaube ich nicht.

Dass man den Fade-In noch modifizieren kann, abseits der Main Settings, finde ich ne coole Sache. Bin aber auch mit dem Standard sonst ganz zufrieden. Ich nutze ja gerne diesen BlackBoxOut-Effekt bei Raumwechsel.

Von den Zeiteinheiten her kann man wahrscheinlich mit 60 FPS am einfachsten rechnen.


BG
der Volltanker

[AmigaMaster]

Mit welcher Taste aktivierst Du denn die HotSpot-Anzeige?

Taste h - ich habe schon vergessen, wo ich das gelesen habe. Vermutlich irgendwo im Sourcecode?

[AmigaMaster]

Meine Experimente von heute:

• Konfigurierbarer Ein- und Ausblendeffekt für Hotspots
• Umbenennung der Variables.* zu GameConfig.*. In der GameConfig.asc können jetzt einige Parameter eingestellt werden. Anfänglich dachte ich, es wäre praktisch in einer einzigen Datei unterschiedliche Einstellmöglichkeiten für das Starterpack zu haben. Mittlerweile kenne ich zumindest das ShowHotspots Script so gut, dass ich es nicht mehr bräuchte - Einstellbar sind dort jetzt:
  
  • Farbe der Hotspots
  • Transparenzwert für den Fade-in/out Effekt
  • Geschwindigkeit für den Fade-in/out Effekt
  • Hotspot Key
  • Hotspot FontType
  • Ob die Hotspottexte in Großbuchstaben angezeigt werden sollen

• Maximale Hotspots für die Hotspotanzeige für AGS 3.6 angepasst (50)
• Umlautkonvertierung ist Dank UTF-Unterstützung für die Hotspot Textanzeige nicht mehr notwendig.
• Hotspot Textanzeige reaktiviert und über die GameConfig konfigurierbar gemacht. Standardmäßig sind die Texte für die Hotspots aber deaktiviert, da sie doch sehr stören können, vor allem in der Küche

https://github.com/AmigaMaster/Maniacweed-Bernard

So sieht es jetzt aus, wenn man die Hotspot-Textanzeige aktiviert und als Schriftart 3 bzw. eFontTumbleTiny einstellt:
Sie dürfen diesen Dateianhang nicht ansehen.

[1mal_volltanken]

Ja. Das hat doch schon was.

Richtig gute Arbeit. Schätze, der eine oder andere wird das gerne nutzen.

Die Schrift ist zwar klein aber trotzdem gut lesbar.

Bei einem 320x200 bzw. 320x180 -Bildschirm ist es schon schwieriger, das optimal hinzukriegen, denn entweder sieht es sonst verpixelt aus oder verschwommen.

Aber irgendwie sind wir ja immer diesem Screen-Format treu geblieben, auch wenn man da weniger detailiert arbeiten kann als mit größeren Auflösungen.


BG
der Volltanker

[AmigaMaster]

Nur um das klarzustellen und hervorzuheben:

Der Code für das Erzeugen und Auslesen der Namen für Objekte, Charaktere und Hotspots war schon in der Funktion enthalten, da hat KhrisMUC mit seinem ShowHotspots3.1 Script die ganze Arbeit gemacht. Es fehlte dann aber die Übergabe der Informationen in die Bildschirmausgabe. Das wird vermutlich bewusst deaktiviert gewesen sein aber von dem, was ich jetzt so getestet habe, scheint es zu funktionieren.

Ich habe heute die letzten Einstellungsmöglichkeiten des ShowHotspots Scripts (Iconauswahl, Icon X & Y Offsets sowie in das generelle Ein- und Ausschalten der Hotspotanzeige) mit in die GameConfig.asc übernommen. Alle bestehenden Funktionen der ShowHotspots sind weiterhin vorhanden, so dass auch vorhandener Code laufen müsste.

Die folgenden zwei Zeilen machen also effektiv dasselbe:

Code Auswählen Erweitern

ShowHotspotsConfig.Enabled = true;
ShowHotspots.Enable();


[AmigaMaster]

Ich hatte noch die WalkTo Routine auf dem Plan, die mich in vielen anderen Adventures auch ein wenig nervt und an der ich mich versucht habe.

Änderungen:

• Code Cleanup und Namen vereinheitlicht (ShowHotspotsConfig anstatt ShowHotspotConfig)
• Kein versehentliches Rennen mehr bei einem Raumwechsel (Das konnte passieren, wenn man den Raum gewechselt hat und dann im richtigen Zeitfenster im neuen Raum den zweiten Mausklick gemacht hat)
• Der Charakter bewegt sich jetzt auch bei langsamer Gehgeschwindigkeit dauerhaft in Richtung Mauspfeil, so lange man die linke Maustaste gedrückt hält
• Koordinaten- und Distanzberechnung für die dauerhafte Bewegung (Gehen und Rennen) erfolgen jetzt nur noch mit AGS 3.6 Funktionen, da auch an anderen Stellen in den Scripten AGS 3.5 bzw. 3.6 vorausgesetzt wird.
• Charakter fängt nicht mehr an zu rennen, wenn man die Maustaste loslässt und kurz danach einmal klickt

https://github.com/AmigaMaster/Maniacweed-Bernard

[Cmdr]

Wow, mit diesen ganzen Verbesserungen werden zukünftige MMM-Episoden ja schon fast zu modernen Spielen. 
Ob noch ein weiteres Ronmaster der Ronmastered Collection notwendig ist? 

Weiß jemand, warum man die ganzen Wait() vor unzähligen Aktionen gemacht hat, auch bei den Dialogen? Die Verzögern doch nur minimal (125ms) die nächste Aktion und eigentlich braucht man sie die meiste Zeit doch nicht, außer man will bewusst eine Verzögerung haben. Oder hat das andere Hintergründe, weil dann etwas anderes nicht funktioniert hat?

Die leichte Verzögerung vor jeder Aktion halte ich auch für sinnvoll. Allerdings ist die damalige Umsetzung, die Pause vor jeder Aktion redundant zu setzen aus entwicklungstechnischer Sicht katastrophal. Die Pause hätte lieber am Ende der any_click_move-Funktion hinzugefügt werden müssen. Dann muss sie a) nur ein einziges Mal implementiert und werden und b) ist sie wirklich vor jeder Aktion vorhanden - man kann sie nicht vergessen.

[Cone Arex]

Die leichte Verzögerung vor jeder Aktion halte ich auch für sinnvoll. Allerdings ist die damalige Umsetzung, die Pause vor jeder Aktion redundant zu setzen aus entwicklungstechnischer Sicht katastrophal. Die Pause hätte lieber am Ende der any_click_move-Funktion hinzugefügt werden müssen. Dann muss sie a) nur ein einziges Mal implementiert und werden und b) ist sie wirklich vor jeder Aktion vorhanden - man kann sie nicht vergessen.

Das Problem daran ist, dass die Verzögerung dann auch vor WalkTo ausgeführt wird. Deswegen wurde das nicht gemacht.