Dead-Ends in C64-Episoden

[Rayman]

Ich habe eine Idee für eine Episode im C64-Stil, würde aber gerne
Elemente wie Sackgassen einbauen, weil ich den Flair von Maniac Mansion und Zak Mckracken
aufbauen möchte.

In allen Versionen von den beiden Adventures gibt es Sackgassen und man kann sterben.
Kann ich das in meiner Episode auch machen, oder sollte das besser vermieden werden,
weil sonst viele Frustfallen entstehen?

Normalerweise kann ich die Frage mir selber beantworten, aber ich will erstmal eure Meinung wissen.
Es hat nämlich noch einen zweiten Grund, warum ich Sackgassen verwenden möchte.

[Stranger]

Ich finde Dead-Ends frustrierend, weil ich mir einfach nicht angewöhnen kann, immerzu zu speichern.

Andererseits finde ich Dead-Ends manchmal die einzig konsequente Antwort auf eine Aktion des Spielers.

Optimal wäre eine Lösung, bei der vor dem Erreichen des Ends (also vor dem Ausführen der beendenden Aktion) automatisch und im Hintergrund gespeichert werden würde und ich danach die Möglichkeit hätte sofort an dieser Stelle weiter zu machen...

[Bòógieman]

da ich noch vom alten schlag bin, finde ich dead-ends nicht so schlimm 
wär aber nicht schlecht, wenn man als spieler irgendwie mitbekommen würde, dass man das spiel verbockt hat

[Kiwa]

In allen Versionen von den beiden Adventures gibt es Sackgassen und man kann sterben.
Kann ich das in meiner Episode auch machen, oder sollte das besser vermieden werden,
weil sonst viele Frustfallen entstehen?

Also wenn die Handlung des Spielers im Kontext des Spiel eindeutig zu einer Sackgasse führt, könnte man es eigentlich einbauen. Es sollte aber zu Beginn des Spiel darauf hingewisen werden das es Sackgassen gibt. Da man sich daran gewöhnt hat das es keine Sackgassen gibt ist diese Info unerlässlich. Oder man gibt dem Spieler zu Beginn die Möglichkeit auszuwählen ob es auch Sackgassen geben darf.

Es hat nämlich noch einen zweiten Grund, warum ich Sackgassen verwenden möchte.

Und welcher ist das?

[Rayman]

Ich würde eine Warnung im Spiel auch einbauen, dass man sich auf Dead-Ends gefasst machen muss.

Und welcher ist das?

In diesem Spiel soll es mehrere Lösungswege geben und der Spieler soll aufgefordert werden
mit seinen Gegenständen vorsichtig umzugehen. Z.B. durfte der Spieler in MM niemals den Entwickler mit
der Fleischfressenden Pflanze benutzen, sonst war nicht nur der Entwickler verschwunden, sondern auch die Pflanze
war dann tot.

@Bòógieman: Keine Sorge, die Fehler werden offensichtlich sein. Nicht so wie bei den Sierra-Spielen,
wenn man einen einzigen wichtigen Gegenstand in einem Ort vergessen hat mitzunehmen, dass man dann
später im Spiel stecken bleibt.

@Stranger: Ich könnte ab den richtigen Stellen im Spielverlauf Hinweise einbauen, indem Bernard sagt "Das wäre jetzt der richtige Moment abzuspeichern."
Ansonsten würde das Al Lowe-Gesetz gelten "Save early save often".

[Stranger]

Ich persönlich kenne mich mit AGS nicht aus...
Aber folgendes habe ich im Netz gefunden:
"SaveGameSlot(998, "Autosave");
 Display("Auto Saved");"
Keine Ahnung, ob das klappt, aber es hört sich ganz plausibel an, oder?
Mit Al Lowes Grundsatz habe ich lediglich das Problem hinterher aus 30 Savegames den gewünschten Spielstand wieder hervor zu holen.

[Kiwa]

"SaveGameSlot(998, "Autosave");
 Display("Auto Saved");"
Keine Ahnung, ob das klappt, aber es hört sich ganz plausibel an, oder?

Ich habe mal bei AGS in die Hilfe geschaut und folgendes gefunden:
-----------------------------------------------------------------------
SaveGameSlot
SaveGameSlot (int slot, string description)

Saves the current game position to the save game number specified by SLOT, using DESCRIPTION as the textual description of the save position. Be careful using this function, because you could overwrite one of the player's save slots if you aren't careful.
The SaveGameDialog function uses slots numbered from 1 to 20, so if you don't want to interfere with the player's saves, I would recommend saving to slot numbers of 100 and above.

NOTE: The game will not be saved immediately; instead, it will be saved when the script function finishes executing.

Example:

SaveGameSlot(30, "save game");

will save the current game position to slot 30 with the description "Save game".
See Also: DeleteSaveSlot, RestoreGameSlot, SaveGameDialog
-------------------------------------------------------------------------------

Sieht so aus als würde es damit gehen. Es darf dann natürlich immer nur ein Autosave-Spielstand geben(hier Nummer 998), ansonsten weiß man wieder nicht welcher der richtige ist. Damit dieser Umstand realisiert werden kann ist es wichtig das es im Spiel keine verschachtelten Sackgassen gibt. Ansonsten wird beim betreten der zweiten Sackgasse der erste Autosave-Spielstand bereits überschrieben. Beim laden würde man dann nur einen Spielstand laden können bei dem man bereits in der ersten Sackgasse feststeckt. Das wäre dann wohl ein "Super Dead End". Da der Spieler aber im Glauben ist das die Autosave Funktion dies verhindert, sucht der Spieler verzweifelt nach einer Lösung die es nicht gibt. Das wäre dann ein Dead End für den Spielspaß.

[fireorange]

Grundsätzlich halte ich ja gar nichts von Dead Ends. In Maniac Mansion haben die ja fast schon Kultstatus und passen irgendwie ins Konzept. Das liegt aber auch an den verschiedenen Loesungswegen und der sehr, sehr kurzen Spiellänge. Bei Zak nervt es schon wieder, weil das Spiel einfach eine ganz andere Struktur hat. Und bei den Sierra-Adventures waren die Dead Ends auch ein unnoetiges Übel, das man eben hinnehmen musste. Aber du hast ja offenbar einen Plan, der die Dead Ends rechtfertigt. Deshalb will ich dich auch nicht aufhalten.

[1mal_volltanken]

Mit dem Beginn der MonkeyIsland-Ära waren Dead-Ends aus den LA-Spielen ja schon komplett wegrationalisiert worden.

Ich finde, ein Spieler sollte zumindest die Freiheit bekommen, auch unsinnige (aber physisch machbare) Aktionen durchzuführen, die er später mitunter auch bereut. Das unsinnige Aktionen oder Versäumnisse (sofern sie auch absehbar sind) bestraft werden, sollte dann auch die Grundlage für Dead-Ends sein.

In ZakMcKracken nenne ich mal das typische Beispiel, wo man auf dem Mars auf der einen Seite mehrere Münzen für die Bahn im voraus kaufen muss, um sich die Option offen zu halten, auch wieder zurückfahren zu können, da ja an der Marspyramide der Automat kaputt ist. Dies war schon ein fieses Dead-End, weil der Spieler dies ja nicht im voraus wissen konnte, wenn er es zum ersten Mal spielt.
Anders ist es in MM mit dem Paket für Ed: Hier kann sich der Spieler denken, dass er nur ne begrenzte Zeit hat, sich das Paket zu krallen. Dabei muss das Verpassen des Pakets nicht zwingend zum Dead-End führen, wenn man nicht Michael mit im Team hat. Bei dem Farb-Entferner hätte man es so machen können, dass der Spieler sagt: "Das wäre aber Verschwendung. Soll ich das WIRKLICH machen?" und man erst bei der zweiten Anwendung das Zeug weghaut. Da es bei falscher Anwendung direkt verloren ist, fand ich dieses Dead-End ebenfalls fies.

Dead-Ends können aber den Wiederspielwert erhöhen.
Von mir also ein ganz klares Ja zu Dead-Ends. Neben C64-Episoden darf das auch für normale Episoden gelten.


BG
der Volltanker

 

[MalleTheRedPhoenix]

Ich bin zwar auch kein großer Freund von Dead-Ends, aber es hängt immer davon ab, ob diese auch nachvollziehbar sind.

Die meisten Sierra-Adventurespiele dienen da als schlechte Beispiele, da die Dead-Ends in diesen Spielen meist auf zunächst unerklärliche Weise zustande kommen. In dem Fall muss man häufig um die Ecke denken, um die Auflösung finden und den Sinn dahinter verstehen zu können. (Falls überhaupt ein Sinn bei bestimmten Sackgassen vorhanden ist)

Bei den früheren LucasArts-Adventurespielen (Labyrinth, Maniac Mansion, Zak McKracken und Indiana Jones and the Last Crusade) hatte man immer 'ne gewisse Ahnung gehabt, weshalb man nicht mehr voran kam. Klar hatte man sich da genauso geärgert als bei den Sierra-Spielen. Aber bei den LA-Spielen war es zumindest nachvollziehbarer gewesen.

Und wie FireOrange sagte: Solange Du ein vernünftiges Konzept hast, kannst Du es ruhig mit ein arbeiten, Rayman!

Mit dem Beginn der MonkeyIsland-Ära waren Dead-Ends aus den LA-Spielen ja schon komplett wegrationalisiert worden.

Es gibt da aber eine Ausnahme, soweit ich mich erinnern kann. Wobei man sich fragen muss, ob es sich hier eher um einen Bug oder tatsächlich um eine Sackgasse handelt. Dieser kommt nämlich in LeChuck's Revenge: Monkey Island 2 vor:

Spoiler (hover to show)

Man bekommt von der VooDoo-Priesterin kurz vor dem dritten Akt eine Tüte mit, den man bei Wally abgeben soll. Schaut man sofort rein, findet man dort eine Streichholzschachtel und eine Liebesbombe darin. Jetzt nehmen wir aber mal an, dass wir es bis zu einem bestimmten Abschnitt im dritten Akt noch nicht getan haben. Dieser Moment wäre, wenn sich Guybrush und Wally im dunklen Raum von LeChuck's Festung versteckt haben. In dem Moment müsste man normalerweise die Streichholzschachtel benutzen. Diese befindet sich aber immer noch in der Tüte, die man sich vorher nicht genau angeschaut hat. Will man dies tun, wird Guybrush aber nicht mehr reinschauen, weil es im Raum zu dunkel ist, um was sehen zu können. Heißt also, man muss schon vorher in die Tüte reingucken, bevor man in die entsprechende Situation gerät. Ansonsten kommt man nicht mehr im Spiel weiter.

Jedenfalls kann ich mich noch gut daran erinnern, weil ich mal selbst in die Situation geraten bin.

Frage ist, wie es sich mit dem ScummVM-Emulator verhält, ob sie da was in dem Fall optimiert haben. Zumindest war es bei dem Briefkasten-Bug von Maniac Mansion der Fall gewesen.

[fireorange]

Ich habe mal bei AGS in die Hilfe geschaut und folgendes gefunden:
-----------------------------------------------------------------------
SaveGameSlot
SaveGameSlot (int slot, string description)

Saves the current game position to the save game number specified by SLOT, using DESCRIPTION as the textual description of the save position. Be careful using this function, because you could overwrite one of the player's save slots if you aren't careful.
The SaveGameDialog function uses slots numbered from 1 to 20, so if you don't want to interfere with the player's saves, I would recommend saving to slot numbers of 100 and above.

NOTE: The game will not be saved immediately; instead, it will be saved when the script function finishes executing.

Example:

SaveGameSlot(30, "save game");

Hierzu eine Frage:
Laut Hilfe ist der Befehl noch aktuell, aber bei mir funktioniert er nicht. Kann mir jemand sagen, woran das liegen koennte?

[Cmdr]

Also bei mir in AGS 3.3.2 wird er zumindest über die Autocompletion angezeigt.
Ob er auch genau das tut was er soll, habe ich jetzt nicht getestet.

Edit: Gerade getestet. Funktioniert wirklich nicht - irgendwie ist der Befehl außer Funktion. Ich tippe auf einen Bug in AGS.

[fireorange]

Ich brauche die Funktion allerdings. Wenn jemand eine Loesung kennt, bitte posten! Danke!

Edit: Ich habe für mich eine Alternative gefunden, sodass ich nicht mehr auf Autosaves angewiesen bin.